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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document specifies the RLC protocol. 
Features for the current Release: 

Transparent mode. 

Unacknowledged mode. 
- Acknowledged mode. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 25.401: "UTRAN Overall Description". 

[2] 3GPP TR 25.990: "Vocabulary for the UTRAN" . 

[3] 3GPP TS 25.301: "Radio Interface Protocol Architecture". 

[4] 3GPP TS 25.302: "Services Provided by the Physical Layer". 

[5] 3GPP TS 25.303: "Interlayer Procedures in Connected Mode". 

[6] 3GPP TS 25.304: "UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected 

Mode". 

[7] 3GPP TS 25.321: "MAC Protocol Specification". 

[8] 3GPP TS 25.331: "RRC Protocol Specification". 



3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ARQ Automatic Repeat Request 

BCCH Broadcast Control Channel 

BCH Broadcast Channel 

C- Control- 

CCCH Common Control Channel 

CCH Control Channel 

CCTrCH Coded Composite Transport Channel 

CRC Cyclic Redundancy Check 

DCCH Dedicated Control Channel 

DCH Dedicated Channel 

DL Downlink 

DSCH Downhnk Shared Channel 
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DTCH Dedicated Traffic Channel 

FACH Forward Link Access Channel 

FDD Frequency Division Duplex 

LI Layer 1 (physical layer) 

L2 Layer 2 (data link layer) 

L3 Layer 3 (network layer) 

LI Length Indicator 

LSB Least Significant Bit 

MAC Medium Access Control 

MRW Move Receiving Window 

MSB Most Significant Bit 

PCCH Paging Control Channel 

PCH Paging Channel 

PDU Protocol Data Unit 

PHY Physical layer 

PhyCH Physical Channels 

RACH Random Access Channel 

RLC Radio Link Control 

RRC Radio Resource Control 

SAP Service Access Point 

SDU Service Data Unit 

SHCCH Shared Channel Control Channel 

SN Sequence Number 

SUFI Super Field 

TCH Traffic Channel 

TDD Time Division Duplex 

TFI Transport Format Indicator 

TTI Transmission Time Interval 

U- User- 

UE User Equipment 

UL Uplink 

UMTS Universal Mobile Telecommunications System 

UTRA UMTS Terrestrial Radio Access 

UTRAN UMTS Terrestrial Radio Access Network 



General 



4.1 



Void 



4.2 Overview on sublayer architecture 

The model presented in this subclause is not for implementation purposes. 



4.2.1 



IVIodel of RLC 



Figure 4.1 gives an overview model of the RLC layer. The figure illustrates the different RLC peer entities. There is one 
transmitting and one receiving entity for the transparent mode service and the unacknowledged mode service and one 
combined transmitting and receiving entity for the acknowledged mode service. In this specification the word 
transmitted is equivalent to "submitted to lower layer" unless otherwise explicitly stated. The dashed lines between the 
AM-Entities illustrate the possibility to send the RLC PDUs on separate logical channels, e.g. control PDUs on one and 
data PDUs on the other. More detailed descriptions of the different entities are given in subclauses 4.2.1.1, 4.2.1.2 and 
4.2.1.3. 
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Higher layer 



RLC 



MAC 




Figure 4.1 : Overview model of RLC 
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4.2.1 .1 Transparent mode entities 

Figure 4.2 below shows the model of two transparent mode peer entities. 
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Figure 4.2: IVIodel of two transparent mode peer entities 

The transmitting Tr-entity receives SDUs from the upper layers through the Tr-SAP. RLC might segment the SDUs into 
appropriate RLC PDUs without adding any overhead. How to perform the segmentation is decided upon when the 
service is established. RLC delivers the RLC PDUs to lower layer through either a BCCH, DCCH, PCCH, CCCH, 
SHCCH or a DTCH. The CCCH and SHCCH uses transparent mode only for the uplink. Which type of logical channel 
depends on if the upper layer is located in the control plane (BCCH, DCCH, PCCH, CCCH, SHCCH) or user plane 
(DTCH). 

The receiving Tr-entity receives PDUs through one of the logical channels from lower layer. RLC reassembles 

(if segmentation has been performed) the PDUs into RLC SDUs. How to perform the reassembling is decided upon 

when the service is estabhshed. RLC delivers the RLC SDUs to the upper layer through the Tr-SAP. 

4.2.1 .2 Unacknowledged mode entities 

Figure 4.3 below shows the model of two unacknowledged mode peer entities. 



ETSI 



3GPP TS 25.322 version 4.1.0 Release 4 



11 



ETSI TS 125 322 V4.1.0 (2001-06) 



B UM -S 



Radio Interface 



UM -SAP 



Transm ission 
buffer 



Segmentation & 
C oncatenation 



Add RLC header 



C ipherin^ 



Transm . 
UM -Entity 



^ ■ ccct 

H DTCf 
H CTCE 



CCCH/DCCH/ 
DTCH/SHCCH 
CTCH 



R eceiver 
U M -Entity 




UM -SAP 



Reassembly 



Remove RLC 
header 



Receiver 
buffer 



D ecipherin c 




CCCH/DCCH/D 
TCH/ SHCCH 



CTCH 



Figure 4.3: IVIodel of two unacknowledged mode peer entities 

The transmitting UM-entity receives SDUs from the upper layers. RLC might segment the SDUs into RLC PDUs of 
appropriate size. The SDU might also be concatenated with other SDUs. RLC delivers the RLC PDUs to lower layer 
through either a CCCH, SHCCH, DCCH, CTCH or a DTCH. The CCCH and SHCCH uses unacknowledged mode only 
for the downlink. Which type of logical channel depends on if the upper layer is located in the control plane (CCCH, 
DCCH, SHCCH) or user plane (CTCH, DTCH). 

The receiving UM-entity receives PDUs through one of the logical channels from the MAC sublayer. RLC removes 
header from the PDUs and reassembles the PDUs (if segmentation has been performed) into RLC SDUs. The RLC 
SDUs are delivered to the upper layer. 



4.2.1.3 



Acknowledged mode entity 



Figure 4.4 below shows the model of an acknowledged mode entity, when one logical channel (shown as a solid line) 
and when two logical channels (shown as dashed lines) are used. 

In case two logical channels are used in the uplink the first logical channel shall be used for data PDUs and the second 
logical channel shall be used for control PDUs. In case one logical channel is used, the RLC PDU size shall be the same 
for AMD PDUs and control PDUs. 
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Figure 4.4: IVIodel of an acknowledged mode entity 

The transmitting side of the AM -entity receives SDUs from the upper layers. The SDUs are segmented and/or 
concatenated to PDUs of fixed length. PDU length is a semi-static value that is decided in bearer setup and can only be 
changed through bearer reconfiguration by upper layers. 

For concatenation or padding purposes, bits of information on the length and extension are inserted into the beginning 
of the last PDU where data from an SDU is included. Padding can be replaced by piggybacked status information. This 
includes setting the poll bit. 

If several SDUs fit into one PDU, they are concatenated and the appropriate length indicators are inserted into the 
beginning of the PDU. After that the PDUs are placed in the retransmission buffer and the transmission buffer. 

The MUX then decides which PDUs and when the PDUs are submitted to the lower layer. The PDUs are submitted via 
a function that completes the AMD PDU header and potentially replaces padding with piggybacked status information. 
The RLC entity shall assume a PDU to be transmitted when the PDU is submitted to lower layer. 

The ciphering is applied only for AMD PDUs. The fixed 2 octets AMD PDU header is not ciphered. Piggybacked 
STATUS PDU and Padding parts of AMD PDU when existing are ciphered. The other Control PDUs (i.e. STATUS 
PDU, RESET PDU, and RESET ACK PDU) shall not be ciphered. 

When Piggybacking mechanism is applied the padding is replaced by control information, in order to increase the 
transmission efficiency and making possible a faster message exchange between the peer-to-peer RLC entities. The 
piggybacked control information is not saved in any retransmission buffer. The piggybacked control information is 
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contained in the piggybacked STATUS PDU, which is in turn included into the AMD-PDU. The piggybacked STATUS 
PDUs will be of variable size in order to match with the amount of free space in the AMD PDU. 

The retransmission buffer also receives acknowledgements from the receiving side, which are used to indicate 
retransmissions of PDUs and when to delete a PDU from the retransmission buffer. 

The receiving side of the AM-entity receives PDUs through one of the logical channels from lower layer. Piggybacked 
status information is extracted, if present. The PDUs are placed in the receiver buffer until a complete SDU has been 
received. The receiver buffer requests retransmissions of PDUs by sending negative acknowledgements to the peer 
entity. After that the RLC headers are removed from the PDUs and the PDUs are reassembled into an SDU. Finally the 
SDU is delivered to the upper layer. The receiving side also receives acknowledgements from the peer entity. The 
acknowledgements are passed to the retransmission buffer on the transmitting side. 



5 Functions 

The following functions are supported by RLC. For a detailed description of the following functions see [3]: 
Segmentation and reassembly. 
Concatenation. 
Padding. 

Transfer of user data. 
Error correction. 

In-sequence delivery of upper layer PDUs. 
Duplicate detection. 
Flow control. 
Sequence number check. 
Protocol error detection and recovery. 

- Ciphering. 
Polling. 

Status transmission. 

- SDU discard. 

Estimated PDU Counter (EPC) mechanism. 
Suspend/resume function. 
Stop/continue function. 
Re-establishment function. 

6 Services provided to upper layers 

This clause describes the different services provided by RLC to upper layers. It also includes mapping of functions to 
different services. For a detailed description of the following functions see [3]. 

- Transparent data transfer Service: 

The following functions are needed to support transparent data transfer: 
Segmentation and reassembly. 
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Transfer of user data. 

- Unacknowledged data transfer Service: 

The following functions are needed to support unacknowledged data transfer: 

- Segmentation and reassembly. 
Concatenation. 

Padding. 

Transfer of user data. 

- Ciphering. 

Sequence number check. 

- Acknowledged data transfer Service: 

The following functions are needed to support acknowledged data transfer: 
Segmentation and reassembly. 
Concatenation. 
Padding. 

Transfer of user data. 
Error correction. 

In-sequence delivery of upper layer PDUs. 
Duplicate detection. 
Flow Control. 

Protocol error detection and recovery. 
Ciphering. 

- Maintenance of QoS as defined by upper layers. 

- Notification of unrecoverable errors. 

6.1 Mapping of services/functions onto logical channels 

The following tables show the applicability of services and functions to the logical channels in UL/DL and 
UE/UTRAN. A '+' in a column denotes that the service/function is applicable for the logical channel in question 
whereas a '-' denotes that the service/function is not applicable. 
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Table 6.1 : RLC modes and functions in UE uplinl< side 



Service 


Functions 


CCCH 


SHCCH 


DCCH 


DTCH 


Transparent 
Service 


Applicability 


+ 


+ 


+ 


+ 


Segmentation 




- 


+ 


+ 


Transfer of user data 


+ 


+ 


+ 


+ 


Unaclcnowledged 
Service 


Applicability 


- 


- 


+ 


+ 


Segmentation 




- 


+ 


+ 


Concatenation 




- 


+ 


+ 


Padding 


- 


- 


+ 


+ 


Transfer of user data 


- 


- 


+ 


+ 


Cipfiering 




- 


+ 


+ 


Acltnowledged 
Service 


Applicability 




- 


+ 


+ 


Segmentation 


- 


- 


+ 


+ 


Concatenation 




- 


+ 


+ 


Padding 




- 


+ 


+ 


Transfer of user data 


- 


- 


+ 


+ 


Flow Control 


- 


- 


+ 


+ 


Error Correction 




- 


+ 


+ 


Protocol error correction & 
recovery 




- 


+ 


+ 


Cipfiering 


- 


- 


+ 


+ 



Table 6.2: RLC modes and functions in UE downlink side 



Service 


Functions 


BCCH 


PCCH 


SHCCH 


CCCH 


DCCH 


DTCH 


CTCH 


Transparent 
Service 


Applicability 


+ 


+ 


- 


- 


+ 


+ 


- 


Reassembly 






- 


- 


+ 


+ 


- 


Unacltnowledged 
Service 


Applicability 






+ 


+ 


+ 


+ 


+ 


Reassembly 


- 


- 


+ 


+ 


+ 


+ 


+ 


Deciphering 


- 


- 


- 


- 


+ 


+ 


- 


Sequence number cfieck 






+ 


+ 


+ 


+ 


+ 


Acltnowledged 
Service 


Applicability 






- 


- 


+ 


+ 


- 


Reassembly 


- 


- 


- 


- 


+ 


+ 


- 


Error correction 






- 




+ 


+ 




Flow Control 






- 




+ 


+ 




In sequence delivery 


- 


- 


- 


- 


+ 


+ 


- 


Duplicate detection 


- 


- 


- 


- 


+ 


+ 


- 


Protocol error correction 
& recovery 






- 


- 


+ 


+ 


- 


Deciphering 






- 


- 


+ 


+ 


- 



Table 6.3: RLC modes and functions in UTRAN downlink side 



Service 


Functions 


BCCH 


PCCH 


CCCH 


SHCCH 


DCCH 


DTCH 


CTCH 


Transparent 
Service 


Applicability 


+ 


+ 


- 


- 


+ 


+ 


- 


Segmentation 


- 


- 


- 


- 


+ 


+ 


- 


Transfer of user data 


+ 


+ 




- 


+ 


+ 


- 


Unaclcnowledged 
Service 


Applicability 


- 




+ 


+ 


+ 


+ 


+ 


Segmentation 


- 


- 


+ 


+ 


+ 


+ 


+ 


Concatenation 


- 


- 


+ 


+ 


+ 


+ 


+ 


Padding 


- 




+ 


+ 


+ 


+ 


+ 


Ciphering 








- 


+ 


+ 


- 


Transfer of user data 


- 


- 


+ 


+ 


+ 


+ 


+ 


Aclcnowledged 
Service 


Applicability 


- 


- 


- 


- 


+ 


+ 


- 


Segmentation 


- 






- 


+ 


+ 


- 


Concatenation 


- 


- 


- 


- 


+ 


+ 


- 


Padding 


- 


- 


- 


- 


+ 


+ 


- 


Transfer of user data 


- 






- 


+ 


+ 


- 


Flow Control 


- 






- 


+ 


+ 


- 


Error Correction 


- 


- 


- 


- 


+ 


+ 


- 


Protocol error correction 
& recovery 


- 


- 


- 


- 


+ 


+ 


- 


Ciphering 


- 






- 


+ 


+ 


- 
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Table 6.4: RLC modes and functions in UTRAN uplinl< side 



Service 


Functions 


CCCH 


SHCCH 


DCCH 


DTCH 


Transparent 
Service 


Applicability 


+ 


+ 


+ 


+ 


Reassembly 






+ 


+ 


Unacknowledged 
Service 


Applicability 


- 


- 


+ 


+ 


Reassembly 


- 


- 


+ 


+ 


Deciphering 






+ 


+ 


Sequence number check 






+ 


+ 


Acknowledged 
Service 


Applicability 


- 


- 


+ 


+ 


Reassembly 


- 


- 


+ 


+ 


Error correction 






+ 


+ 


Flow Control 




- 


+ 


+ 


In sequence delivery 




- 


+ 


+ 


Duplicate detection 




- 


+ 


+ 


Protocol error correction & 
recovery 






+ 


+ 


Deciphering 






+ 


+ 



7 



Services expected from MAC 



For a detailed description of the following functions see [3]. 
Data transfer. 



8 



Elements for layer-to-layer communication 



The interaction between the RLC layer and other layers are described in terms of primitives where the primitives 
represent the logical exchange of information and control between the RLC layer and other layers. The primitives shall 
not specify or constrain implementations. 

8.1 Primitives between RLC and upper layers 

The primitives between RLC and upper layers are shown in Table 8.1. 

Table 8.1 : Primitives between RLC and upper layers 



Generic Name 


Parameter 


Req. 


Ind. 


Resp. 


Conf. 


RLC-AM-DATA 


Data, CNF, MUl 


Data, Discardlnfo 


Not Defined 


MUl 


RLC-UM-DATA 


Data, Use special LI 


Data 


Not Defined 


Not Defined 


RLC-TR-DATA 


Data 


Data 


Not Defined 


Not Defined 


CRLC-CONFIG 


E/R, Stop, Continue, 
Ciphering Elements 

(UM/AM only), 

TM_parameters (TM 

only), UM parameters 

(UMonly), 

AM_parameters (AM 

only) 


Not Defined 


Not Defined 


Not Defined 


CRLC-SUSPEND 


N 


Not Defined 


Not Defined 


VT(US) (UMonly), 


(UM/AM only) 








VT(S) (AM only) 


CRLC-RESUME 


No Parameter 


Not Defined 


Not Defined 


Not Defined 


(UM/AM only) 










CRLC-STATUS 


Not Defined 


EVC 


Not Defined 


Not Defined 



Each Primitive is defined as follows: 
RLC-AM-DATA-Req/Ind/Conf 
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RLC-AM-DATA-Req is used by upper layers to request transmission of an upper layer PDU in acknowledged 
mode. 

RLC-AM-DATA-Ind is used by RLC to deliver to upper layers RLC SDUs that have been transmitted in 
acknowledged mode and to indicate upper layers of the discarded RLC SDU in the peer RLC AM entity. 

RLC-AM-DATA-Conf is used by RLC to confirm to upper layers reception of an RLC SDU by the peer-RLC 

AM entity. 

RLC-UM-DATA-Req/Ind 

RLC-UM-DATA-Req is used by upper layers to request transmission of an upper layer PDU in unacknowledged 
mode. 

RLC-UM-DATA-Ind is used by RLC to deliver to upper layers RLC SDUs that have been transmitted in 
unacknowledged mode. 

RLC-TR-DATA-Req/Ind 

RLC-TR-DATA-Req is used by upper layers to request transmission of an upper layer PDU in transparent mode. 

RLC-TR-DATA-Ind is used by RLC to deliver to upper layers RLC SDUs that have been transmitted in 
transparent mode. 

CRLC-CONFIG-Req 

This primitive is used by upper layers to establish, re-establish, release, stop, continue or reconfigure the RLC. 
Ciphering elements are included for UM and AM operation. 

CRLC-SUSPEND-Req/Conf 

This primitive is used by upper layers to suspend the RLC. The N parameter indicates that RLC shall not send a PDU 
with SN>=VT(S)+N for AM and SN>=VT(US)+N for UM, where N is an integer. RLC informs upper layers of the 
VT(S) for AM and VT(US) for UM in the confirm primitive. 

CRLC-RESUME-Req 

This primitive is used by upper layers to resume RLC when RLC has been suspended. 

CRLC-STATUS-Ind 

It is used by the RLC to send status information to upper layers. 

8.2 Primitive parameters 

Following parameters are used in the primitives: 

1) The parameter Data is the RLC SDU that is mapped onto the Data field in RLC PDUs. The Data parameter may 
be divided over several RLC PDUs. In case of an RLC-AM-DATA or an RLC-UM-DATA primitive the length 
of the Data parameter shall be octet-aligned. 

2) The parameter Confirmation request (CNF) indicates whether the RLC needs to confirm the reception of the 
RLC SDU by the peer-RLC AM entity. 

3) The parameter Message Unit Identifier (MUI) is an identity of the RLC SDU, which is used to indicate which 
RLC SDU that is confirmed with the RLC-AM-DATA conf. primitive. 

4) The parameter E/R indicates (re)establishment, release or modification of RLC, where re-establishment is 
applicable for AM and UM RLC entities only. If it indicates (re-)establishment, the state variables and 
configurable parameters are initialised according to subclause 9.7.7. If it indicates release, all protocol 
parameters, variables and timers shall be released and RLC shall exit the data transfer ready state. If it indicates 
modification, the protocol parameters indicated by upper layers (e.g. ciphering parameters) shall only be 
modified with keeping the other protocol parameters, the protocol variables, the protocol timers and the protocol 
state. AM RLC entities shall always be re-established if the AMD PDU size is changed. The modification of 
other protocol parameters does not warrant re-establishment. 
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5) The parameter Event Code (EVC) indicates the reason for the CRLC-STATUS-ind (e.g., unrecoverable errors 
such as data Hnk layer loss or recoverable status events such as reset.). 

6) The parameter ciphering elements are only applicable for UM and AM operation. These parameters are 
Ciphering Mode, Ciphering Key, Transmitting Activation Time (SN to activate a new ciphering configuration at 
the transmitter). Receiving Activation Time (SN to activate a new ciphering configuration at the receiver) and 
HFN (Hyper Frame Number). 

7) The AM_parameters are only applicable for AM operation. It contains AMD PDU size, In-sequence Delivery 
Indication (indicating that SDUs shall be deliver to the upper layers in sequence or out of sequence). Timer 
values (see subclause 9.5), Protocol parameter values (see subclause 9.6), Polling triggers (see subclause 9.7.1), 
Status triggers (see subclause 9.7.2), Periodical Status blocking configuration (see subclause 9.7.2), SDU discard 
mode (see subclause 9.7.3), Minimum WSN (see subclause 9.2.2.11.3), and Send MRW. The Minimum WSN 
shall always be greater than or equal to the number of transport blocks in the smallest transport block set. The 
Send MRW indicates that the information of each discarded SDU shall be sent to the receiver, and the MRW 
SUFI shall be sent to the receiver even if no segments of the SDU to be discarded were submitted to a lower 
layer. 

8) The parameter Discardlnfo indicates to upper layer the discarded RLC SDU in the peer-RLC AM entity. It is 
applicable only when in-sequence delivery is active and it is purposed to be used when the upper layer requires 
the reliable data transfer and especially the information of the discarded RLC SDU. 

9) The Stop parameter indicates that the RLC entity shall not transmit or receive RLC PDUs. The Continue 
parameter indicates that the RLC entity shall continue transmission and reception of RLC PDUs. 

10) The parameter Use special LI indicates that the LI indicating that an RLC SDU begins in the beginning of an 
RLC PDU (the first data octet of the PDU is the first octet of an SDU) shall be used. If the RLC SDU does not 
begin in the beginning of the RLC PDU, or if the LI indicating that an SDU ended exactly in the end or one octet 
short (only when 15 bit LI is used) of the previous RLC PDU is present, the LI shall not be used. 

1 l)The UM_parameters are only applicable for UM operation. It contains Timer_Discard value (see subclause 9.5) 
and largest UMD PDU size (see subclause 9.2.2.8). 

12) The TM_parameters are only applicable for TM operation. It contains e.g. segmentation indication (see 
subclauses 9.2.2.9 and 11.1.2.1), Timer_Discard value (see subclause 9.5) and delivery of erroneous SDU 
indication (see subclause 11.1.3). 



9 Elements for peer-to-peer communication 

9.1 Protocol data units 
9.1.1 Data PDUs 

a) TrD PDU (Transparent Mode Data PDU). 

The TrD PDU is used to convey RLC SDU data without adding any RLC overhead. The TrD PDU is used by 
RLC when it is in transparent mode. 

b) UMD PDU (Unacknowledged Mode Data PDU). 

The UMD PDU is used to convey sequentially numbered PDUs containing RLC SDU data. It is used by RLC 
when using unacknowledged data transfer. 

c) AMD PDU (Acknowledged Mode Data PDU). 

The AMD PDU is used to convey sequentially numbered PDUs containing RLC SDU data. The AMD PDU is 
used by RLC when it is in acknowledged mode. 
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9.1.2 Control PDUs 

a) STATUS PDU and Piggybacked STATUS PDU 

The STATUS PDU and the Piggybacked STATUS PDU are used in acknowledged mode: 

- by the receiving entity to inform the transmitting entity about missing PDUs at the receiving entity; 

- by the receiving entity to inform the transmitting entity about the size of the allowed transmission window; 
and by the transmitting entity to request the receiving entity to move the receiving window. 

b) RESET PDU 

The RESET PDU is used in acknowledged mode to reset all protocol states, protocol variables and protocol 
timers of the peer RLC entity in order to synchronise the two peer entities. 

c) RESET ACK PDU 

The RESET ACK PDU is an acknowledgement to the RESET PDU. 

Table 9.1 : RLC PDU names and descriptions 



Data Transfer Mode 


PDU name 


Description 


Transparent 


TrD 


Transparent mode data 


Unacknowledged 


UMD 


Sequenced unacknowledged mode data 


Acknowledged 


AMD 


Sequenced acknowledged mode data 


STATUS 


Solicited or Unsolicited Status Report 


Piggybacked 
STATUS 


Piggybacked Solicited or Unsolicited Status Report 


RESET 


Reset Command 


RESET ACK 


Reset Acknowledgement 



9.2 Formats and parameters 



9.2.1 Formats 

This subclause specifies the format of the RLC PDUs. The parameters of each PDU are explained in subclause 9.2.2. 



9.2.1.1 



General 



An RLC PDU is a bit string, with a length not necessarily a multiple of 8 bits. In the drawings in clause 9.2, bit strings 
are represented by tables in which the first bit is the leftmost one on the first line of the table, the last bit is the rightmost 
on the last line of the table, and more generally the bit string is to be read from left to right and then in the reading order 
of the lines. 

Depending on the provided service, RLC SDUs are bit strings, with any non-null length, or bit strings with an integer 
number of octets in length. An SDU is included into an RLC PDU from first bit onward. 



9.2.1.2 



TrD PDU 



The TrD PDU transfers user data when RLC is operating in transparent mode. No overhead is added to the SDU by 
RLC. The data length is not constrained to be an integer number of octets. 



Data 



Figure 9.1: TrD PDU 
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9.2.1.3 



UMDPDU 



The UMD PDU transfers user data when RLC is operating in unacknowledged mode. The length of the data part shall 
be an integer number of octets. The UMD PDU header consists of the first octet, which contains the sequence number. 
The RLC header consists of the first octet and all the octets that contain length indicators. 



Sequence Number 



Length Indicator 



Octl 



(Optional) (1) 



Length Indicator 



Data 



PAD 



(Optional) 



OctN 



(Optional) 



Figure 9.2: UMD PDU 

NOTE (1): The Length Indicator may be 15 bits. 



9.2.1.4 



AMD PDU 



The AMD PDU transfers user data and piggybacked status information and requests status report by setting Poll bit 
when RLC is operating in acknowledged mode. The length of the data part shall be an integer number of octets. The 
AMD PDU header consists of the first two octets, which contain the sequence number. The RLC header consists of the 
first two octets and all the octets that contain length indicators. 



Octl 
Oct2 
Oct3 (Optional) (1) 



D/C Sequence Number 


Sequence Number P 


HE 


Length Indicator 


E 



Length Indicator 


E 


Data 


PAD 


or a piggybacked STATUS PI 


DU 



OctN 



NOTE (1): The Length Indicator may be 15 bits. 

Figure 9.3: Aim D PDU 



9.2.1.5 



STATUS PDU 



The STATUS PDU is used to report the status between two RLC AM entities. Both receiver and transmitter status 
information may be included in the same STATUS PDU. 

The format of the STATUS PDU is given in Figure 9.4 below. The Figure shows an example and the length of each 
SUFI is dependent on the SUFI type. 
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D/C 


PDU type 


SUFI, 


SUFIi 




SUFIk 


PAD 



Oct 1 
Oct2 



OctN 



Figure 9.4: Status Information Control PDU (STATUS PDU) 

Up to K super-fields (SUFI|-SUFIk) can be included into one STATUS PDU, in which each super-field can be of 
different type. The size of a STATUS PDU is variable and upper bounded by the maximum RLC PDU size used by the 
logical channel on which the control PDUs are sent. Padding shall be included to exactly fit one of the PDU sizes used 
by the logical channel on which the control PDUs are sent. The length of the STATUS PDU shall be an integer number 
of octets. 



9.2.1.6 



Piggybacked STATUS PDU 



The format of the piggybacked STATUS PDU is the same as the ordinary Control PDU except that the D/C field is 
replaced by a reserved bit (R2). This PDU can be used to piggyback STATUS PDU in an AMD PDU if the data does 
not fill the complete AMD PDU. The PDU Type field is set to zero and all other values are invalid for this version of 
the protocol and the PDU is discarded. 



R2 PDU Type 



SUFI, 



SUFI, 



SUFIk 



PAD 



Octl 
Oct2 



OctN 



Figure 9.5: Piggybacked STATUS PDU 



9.2.1.7 



RESET, RESET ACK PDU 



The RESET PDU and RESET ACK PDU have a one-bit sequence number field (RSN). With the aid of this field the 
Receiver can define whether the received RESET PDU is transmitted by the Sender for the first time or whether it is a 
retransmission of a previous RESET PDU. 
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D/C PDU Type 



RSN 



HFNI 



HFNI 



HFNI 



PAD 



Rl 



Octl 



OctN 



Figure 9.6: RESET, RESET ACK PDU 

The size of a RESET or RESET ACK PDU is variable and upper bounded by the maximum RLC PDU size used by the 
logical channel on which the control PDUs are sent. Padding shall be included to exactly fit one of the PDU sizes used 
by the logical channel on which the control PDUs are sent. The length of the RESET or RESET ACK PDU shall be an 
integer number of octets. 

9.2.2 Parameters 

If not otherwise mentioned in the definition of each field then the bits in the parameters shall be interpreted as follows: 
the left-most bit string is the first and most significant and the right most bit is the last and least significant bit. 

Unless otherwise mentioned, integers are encoded in standard binary encoding for unsigned integers. In all cases, 
including when a value extends over more than one octet as shown in the tables, the bits appear ordered from MSB to 
LSB when read in the PDU. 

9.2.2.1 D/C field 

Length: Ibit. 

The D/C field indicates the type of an acknowledged mode PDU. It can be either data or control PDU. 



Bit 


Description 





Control PDU 


1 


Acknowledged mode data PDU 



9.2.2.2 PDU Type 

Length: 3 bit. 

The PDU type field indicates the Control PDU type. 



Bit 


PDU Type 


000 


STATUS 


001 


RESET 


010 


RESET ACK 


011-111 


Reserved 




(PDUs with this 




coding will be 




discarded by 




this version of 




the protocol). 



9.2.2.3 Sequence Number (SN) 

This field indicates the sequence number of the PDU, encoded in binary. 
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PDU type 


Length 


Notes 


AMD PDU 


12 bits 


Used for retransmission and reassembly 


UMD PDU 


7 bits 


Used for reassembly 



9.2.2.4 Polling bit (P) 

Length: Ibit. 

This field is used to request a status report (one or several STATUS PDUs) from the receiver RLC. 



Bit 


Description 





Status report not requested 


1 


Request a status report 



9.2.2.5 Extension bit (E) 

Length: Ibit. 

This bit indicates if the next octet will be a length indicator and E bit. 



Bit 


Description 





The next field is data 


1 


The next field is Length Indicator and E bit 



9.2.2.6 Reserved 1 (R1) 

Length: 3 bits. 

This field in the RESET PDU and RESET ACK PDU is used to achieve octet alignment and for this purpose it is coded 
as 000. Other functions of it are left for future releases. 

9.2.2.7 Header Extension Type (HE) 

Length: 2 bits. 

This two-bit field indicates if the next octet will be data or a length indicator and E bit. 



Value 


Description 


00 


The succeeding octet contains data 


01 


The succeeding octet contains a length indicator and E 
bit 


10-11 


Reserved (PDUs with this coding will be discarded by 
this version of the protocol). 



9.2.2.8 



Length Indicator (LI) 



The Length Indicator is used to indicate, each time, the end of an SDU occurs in the PDU. The Length Indicator points 
out the number of octets between the end of the last Length Indicator field and up to and including the octet at the end 
of an SDU segment. Length Indicators are included in the PDUs that they refer to. The size of the Length Indicator may 
be either 7bits or ISbits. The value of a Length Indicator shall not exceed the values specified in subclauses 1 1.2.4.2 
and 11.3.4.5. 

A Length Indicator group is a set of Length Indicators that refer to a PDU. Length Indicators that are part of a Length 
Indicator group must never be reordered within the Length Indicator group or removed from the Length Indicator 
group. 

If there can be more than one Length Indicator, each specifying the end of an SDU in a PDU, the order of these Length 
Indicators must be in the same order as the SDUs that they refer to. 
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In the case where the end of the last segment of an SDU exactly ends at the end of a PDU and there is no LI that 
indicates the end of the SDU, the next Length Indicator, shall be placed as the first Length Indicator in the following 
PDU and have value LI=0. In case this SDU was the last one to be transmitted, a PDU consisting of an RLC Header 
with LI=0 followed by a padding Length Indicator and padding may be transmitted. 

In the case where a PDU contains a 15-bit LI indicating that an SDU ends with one octet left in the PDU, the last octet 
of this PDU shall be ignored and shall not be filled with the first octet of the next SDU data. 

In the case where 15-bit Length Indicators are used for the previous PDU and the last segment of an RLC SDU is one 
octet short of exactly filling the PDU, and: 

- if a 15-bit Length Indicator is used for the following PDU then the LI with value LI=11 1 1111 1111 101 1 shall 
be placed as the first Length Indicator. The remaining one octet shall be ignored at the receiver. In case this SDU 
was the last one to be transmitted, a PDU consisting of an RLC Header with LI=1 1 1 1111 1111 1011 followed 
by a padding Length Indicator and padding may be transmitted. 

if a 7-bit Length Indicator is used for the following PDU then the LI with value LI=0000000 shall be placed as 
the first Length indicator and its SN shall be incremented by 2 before it is transmitted (this can only occur in 

UM). 

A PDU that has unused space, to be referred to as padding, shall use a Length Indicator to indicate that this space is 
used as padding unless the padding size is one octet for PDUs with 15-bit Lis. A padding Length Indicator must be 
placed after any Length Indicators for a PDU. 

All unused space in a PDU must be located at the end of the PDU, be a homogeneous space and is referred to as 
padding. Predefined values of the Length Indicator are used to indicate this. The values that are reserved for special 
purposes are listed in the tables below depending on the size of the Length Indicator. Only predefined Length Indicator 
values can refer to the padding space. 

STATUS PDUs can be piggybacked on the AMD PDU by using part or all of the padding space. A Length Indicator 
must be used to indicate the piggybacked STATUS PDU. This Length Indicator takes space from the padding space or 
piggybacked STATUS PDU and not the PDU data and will always be the last Length Indicator. Where only part of the 
padding space is used by a piggybacked STATUS PDU then the end of the piggybacked STATUS PDU is determined 
by one of the SUFI fields NO_MORE or ACK, thus no additional Length Indicator is required to show that there is still 
padding in the PDU. The padding/piggybacked STATUS PDU predefined Length Indicators shall be added after the 
very last (i.e. there could be more than one SDU that end within a PDU) Length Indicator that indicates the end of the 
last SDU segment in the PDU. 

If SDU discard with explicit signalling is used an AMD PDU can contain a maximum number of 15 Lis indicating the 
end of an SDU and the rest of the AMD PDU space shall be used as padding/piggybacked STATUS PDU. 

For AM, 7bit indicators shall be used if the AMD PDU size is < 126 octets. Otherwise 15bit indicators shall be used. For 
UM, 7bit indicators shall be used if the largest UMD PDU size is < 125 octets. Otherwise 15bit indicators shall be used. 

The length of the Length Indicator only depends on the size of the largest RLC PDU. Between RLC modifications the 
length of the Length Indicator is the same for all UMD PDUs. The length of the Length Indicator is always the same for 
all AMD PDUs, for one RLC entity. 

Length: 7bits 



Bit 


Description 


0000000 


The previous RLC PDU was exactly filled with the last segment of an RLC SDU 
and there is no LI that indicates the end of the SDU in the previous RLC PDU. 


1111100 


UIVID PDU: The first data octet in this RLC PDU is the first octet of an RLC 
SDU. AMD PDU: Reserved (PDUs with this coding will be discarded by this 
version of the protocol). 


1111101 


Reserved (PDUs with this coding will be discarded by this version of the 
protocol). 


1111110 


AIVID PDU: The rest of the RLC PDU includes a piggybacked STATUS PDU. 
UIVID PDU: Reserved (PDUs with this coding will be discarded by this version 
of the protocol). 


1111111 


The rest of the RLC PDU is padding. The padding length can be zero. 



Length: 15bits 
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Bit 


Description 


000000000000000 


The previous RLC PDU was exactly filled with the last segment of an 
RLC SDU and there is no LI that indicates the end of the SDU in the 
previous RLC PDU. 


111111111111011 


The last segment of an RLC SDU was one octet short of exactly filling 
the previous RLC PDU and there is no LI that indicates the end of the 
SDU in the previous RLC PDU. The remaining one octet in the previous 
RLC PDU is ignored. 


111111111111100 


UIVID PDU: The first data octet in this RLC PDU is the first octet of an 
RLC SDU. AMD PDU: Reserved (PDUs with this coding will be 
discarded by this version of the protocol). 


111111111111101 


Reserved (PDUs with this coding will be discarded by this version of the 
protocol). 


111111111111110 


AIVID PDU: The rest of the RLC PDU includes a piggybacked STATUS 
PDU. UMD PDU: Reserved (PDUs with this coding will be discarded by 
this version of the protocol). 


111111111111111 


The rest of the RLC PDU is padding. The padding length can be zero. 



9.2.2.9 



Data field 



RLC SDUs or segments of RLC SDUs are mapped to this field in transparent, unacknowledged and acknowledged 
mode. 

Transparent mode data: 

The length of RLC SDUs is not constrained to a multiple of 8 bits. 

The RLC SDUs might be segmented. The allowed size for the segments shall be determined from the transport formats 
of the transport channel [4, 8]. All the RLC PDUs carrying one RLC SDU shall be sent in one transmission time 
interval. Only segments from one RLC SDU shall be sent in one transmission time interval. 

NOTE: If segmentation is not used for the transparent mode RLC entity then more than one RLC SDU can be 
sent in one transmission time interval using one RLC PDU per RLC SDU. The RLC PDUs need, 
however, to be of the same size due to LI limitations. 

Unacknowledged mode data and Acknowledged mode data: 

The length of RLC SDUs is constrained to a multiple of 8 bits. 

RLC SDUs might be segmented. If possible, the last segment of an SDU shall be concatenated with the first segment of 
the next SDU in order to fill the data field completely and avoid unnecessary padding. The length indicator field is used 
to point the borders between SDUs. 

For PDUs with 15-bit Lis, if an SDU ends with one octet left in a PDU whether the LI indicating the end of the SDU is 
contained in this PDU or in the next PDU, padding for the last octet of this PDU is necessary and the next SDU shall 
not be concatenated in this PDU. No LI shall be needed to indicate this kind of one-octet padding. 

9.2.2.10 Padding (PAD) 

Padding has a length such that the PDU has the required predefined total length. 
Padding may have any value and the receiving entity shall disregard it. 



9.2.2.11 



SUFI 



Which SUFI fields to use is implementation dependent, but when a STATUS PDU includes information about which 
PDUs have been received and which are detected as missing, information shall not be included about PDUs with 
SN>VR(H) i.e. PDUs that have not yet reached the receiver. Information about PDUs with SN<VR(R) shall not be 
given except when this is necessary in order to use the BITMAP SUFI, see 9.2.2. 11 .5. 

Length: variable number of bits. 
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The SUFI (Super-Field) includes three sub-fields: type information (type of super-field, e.g. list, bitmap, 
acknowledgement, etc), length information (providing the length of a variable length field within the following value 
field) and a value. 

Figure 9.7 shows the structure of the super-field. The size of the type sub-field is non-zero but the size of the other 
sub-fields may be zero. 



Type 



Length 



Value 



Figure 9.7: The Structure of a Super-Field 

The length of the type field is 4 bits and it may have any of following values. 



Bit 


Description 


0000 


No More Data (NO IVIORE) 


0001 


Window Size (WINDOW) 


0010 


Acl<nowledgement (ACK) 


0011 


List (LIST) 


0100 


Bitmap (BITMAP) 


0101 


Relative list (Rlist) 


0110 


Move Receiving Window (MRW) 


0111 


Move Receiving Window Acknowledgement 
(MRW_ACK) 


1000- 

1111 


Reserved (PDUs with this encoding are invalid for this 
version of the protocol) 



The length sub-field gives the length of the variable size part of the following value sub-field and the length of it 
depends on the super-field type. The value sub-field includes the value of the super-field, e.g. the bitmap in case of a 
BITMAP super-field, and the length is given by the length of the type sub-field. 



9.2.2.11.1 



The No More Data super-field 



The 'No More Data' super-field indicates the end of the data part of a STATUS PDU and is shown in Figure 9.8 below. 
It shall always be placed as the last SUFI if it is included in a STATUS PDU. All data after this SUFI shall be regarded 
as padding and shall be neglected. 



Type=NO_MORE 



Figure 9.8: NO_MORE field in a STATUS PDU 



9.2.2.11.2 



The Acknowledgement super-field 



The 'Acknowledgement' super-field consists of a type identifier field (ACK) and a sequence number (LSN) as shown in 
Figure 9.9 below. The acknowledgement super-field is also indicating the end of the data part of a STATUS PDU. 
Thus, no 'NO_MORE' super-field is needed in the STATUS PDU when the 'ACK' super-field is present. The ACK 
SUFI shall always be placed as the last SUFI if it is included in a STATUS PDU. All data after this SUFI shall be 
regarded as padding and shall be neglected. 



Type = ACK 



LSN 



Figure 9.9: The ACK fields in a STATUS PDU 



LSN 

Length: 12 bits 
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Acknowledges the reception of all PDUs with sequence numbers < LSN (Last Sequence Number) that are not indicated 
to be erroneous in earlier parts of the STATUS PDU. This means that if the LSN is set to a value greater than VR(R), 
all erroneous PDUs must be included in the same STATUS PDU and if the LSN is set to VR(R), the erroneous PDUs 
can be split into several STATUS PDUs. At the transmitter, if the value of the LSN =< the value of the first error 
indicated in the STATUS PDU, VT(A) will be updated according to the LSN, otherwise VT(A) will be updated 
according to the first error indicated in the STATUS PDU. VT(A) is only updated based on STATUS PDUs where 
ACK SUFI (or MRW_ACK SUFI) is included. The LSN should not be set to a value > VR(H) nor < VR(R). 



9.2.2.11.3 



The Window Size super-field 



The 'Window Size' super-field consists of a type identifier (WINDOW) and a window size number (WSN) as shown in 
Figure 9.10 below. The receiver is always allowed to change the Tx window size of the peer entity during a connection, 
but the minimum and the maximum allowed value is given by upper layers configuration. The Rx window of the 
receiver is not changed. 



Type = WINDOW 



WSN 



Figure 9.10: The WINDOW fields in a STATUS PDU 

WSN 

Length: 12 bits 

The value of VT(WS) to be used by the transmitter. The range of the WSN is [0, 2'^-!]. The minimum value of 
VT(WS) is 1, if WSN is zero the SUFI shall be discarded by this version of the protocol. The variable VT(WS) is set 
equal to WSN upon reception of this SUFI. If WSN is greater than Configured_Tx_Window_Size, VT(WS) shall be set 
equal to Configured_Tx_Window_Size. 



9.2.2.11.4 



The List super-field 



The List Super-Field consists of a type identifier field (LIST), a list length field (LENGTH) and a list of LENGTH 
number of pairs as shown in Figure 9.1 1 below: 



Type = LIST 



LENGTH 



SNi 



SN2 



\-2 



SNlength 



Llengt 



Figure 9.11 : Thie List fields in a STATUS PDU for a list 

LENGTH 

Length: 4 bits 

The number of (SN, , Li)-pairs in the super-field of type LIST. The value "0000" is invaUd and the STATUS PDU is 
discarded. 

SN,- 

Length: 12 bits 

Sequence number of PDU, which was not correctly received. 

L, 

Length: 4 bits 
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Number of consecutive PDUs not correctly received following PDU with sequence number SN,. 

9.2.2.1 1 .5 The Bitmap super-field 

The Bitmap Super-Field consists of a type identifier field (BITMAP), a bitmap length field (LENGTH), a first sequence 
number (FSN) and a bitmap as shown in Figure 9.12 below: 



Type = BITMAP 



LENGTH 



FSN 



Bitmap 



Figure 9.12: The Bitmap fields in a STATUS PDU 

LENGTH 

Length: 4 bits 

The size of the bitmap in octets equals LENGTHh-1, i.e. LENGTH="0000" means that the size of the bitmap is one 
octet and LENGTH="1 1 11" gives the maximum bitmap size of 16 octets. 

FSN 

Length: 12 bits 

The sequence number for the first bit in the bitmap. FSN shall not be set to a value lower than VR(R)-7 when the Rx 
window size is less than half the maximum RLC AM sequence number. If the Rx window size is larger, FSN shall not 
be set to a value lower than VR(R). 

Bitmap 

Length: Variable number of octets given by the LENGTH field. 

Status of the SNs in the interval [FSN, FSN + (LENGTHh-1)*8 - 1] indicated in the bitmap where each position (from 
left to right) can have two different values (0 and 1) with the following meaning 
(bit_positione[0,(LENGTHH-l)*8 - 1]): 

1 : SN = (FSN + bit_position) has been correctly received. 

0: SN = (FSN + bit_position) has not been correctly received. 



9.2.2.11.6 



The Relative List super-field 



The Relative List super-field consists of a type identifier field (RLIST), a list length field (LENGTH), the first sequence 
number (FSN) and a list of LENGTH number of codewords (CW) as shown in Figure 9.13 below. 



Type = RLIST 



LENGTH 



FSN 



GWi 



GW2 



GWlength 



Figure 9.13: The RList fields in a STATUS PDU 

LENGTH 

Length: 4 bits 

The number of codewords (CW) in the super-field of type RLIST. 

FSN 
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Length: 12 bits 

The sequence number for the first erroneous PDU in the RLIST, i.e. LENGTH="0000" means that only FSN is present 
in the SUFI. 

CW 

Length: 4 bits 

The CW consists of 4 bits where the three first bits are part of a number and the last bit is a status indicator and it shall 
be interpreted as follows: 



Code Word 


Description 


X1X2X3 


Next 3 bits of the number are X1X2X3 and the number continues in the next 
CW. The most significant bit within this CW is Xi. 


X1X2X3 1 


Next 3 bits of the number are X1X2X3 and the number is terminated. The 
most significant bit within this CW is Xi. This is the most significant CW 
within the number. 



By default, the number given by the CWs represents a distance between the previous indicated erroneous PDU up to 
and including the next erroneous PDU. 

One special value of CW is defined: 

000 1 'Error burst indicator'. 

The error burst indicator means that the next CWs will represent the number of subsequent erroneous PDUs (not 
counting the already indicated error position). After the number of errors in a burst is terminated with XXX 1, the next 
codeword will again by default be the least significant bits (LSB) of the distance to the next error. 

If the last CW, as indicated by the value of the LENGTH field, does not contain a "1" in its rightmost position, or the 
last CW, as indicated by the value of the LENGTH field does contain a "1" in its rightmost position, but is a special 
"error burst indicator" CW, the encoding of the RLIST SUFI is invalid, and the STATUS PDU is discarded. 



9.2.2.11.7 



The Move Receiving Window Acknowledgement super-field 



The 'Move Receiving Window Acknowledgement' super-field acknowledges the reception of a MRW SUFI. The format 
is given in Figure 9.14 below. 



Type = MRW_ACK 



N 



SN ACK 



Figure 9.14: The MRW-ACK fields in a STATUS PDU 

N 

Length: 4 bits 

The N field shall be set equal to the Nlength field in the received MRW SUFI if the SN_ACK field is equal to the 
SN_MRWlength field. Otherwise N shall be set to 0. 

With the aid of this field in combination with the SN_ACK field, it can be determined if the MRW_ACK corresponds 
to a previously transmitted MRW SUFI. 

SN_ACK 

Length: 12 bits 

The SN_ACK field indicates the updated value of VR(R) after the reception of the MRW SUFI. With the aid of this 
field in combination with the N field, it can be determined if the MRW_ACK corresponds to a previously transmitted 
MRW SUFI. 
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9.2.2.1 1 .8 The Move Receiving Window (MRW) super-field 

The 'Move Receiving Window' super-field is used to request the RLC receiver to move its receiving window and 
optionally to indicate the set of discarded SDUs, as a result of an SDU discard in the RLC transmitter. The format is 
given in Figure 9.15 below. 



Type = MRW 



LENGTH 



SN MRWi 



SN MRW2 



SN_MRWlength 



N 



LENGTH 



Figure 9.15: The IVIRW fields in a STATUS PDU 

LENGTH 

Length: 4 bits 

The number of SN_MRWi fields in the super-field of type MRW. 

The values "0001" through "1111" indicate 1 through 15 SN.MRW, respectively. The value "0000" indicates that one 
SN_MRWi field is present and that the SDU to be discarded in the receiver extends above the configured Tx window in 
the transmitter. 

SN_MRWi 
Length: 12 bits 

When Send MRW is configured, an SN_MRWi shall be used to indicate the end of each discarded SDU, i.e. the number 
of SN_MRWi fields shall equal the number of SDUs discarded by that MRW SUFI. When Send MRW is not 
configured, SN_MRWi shall be used to indicate the end of the last SDU to be discarded in the receiver and they may 
optionally be used to indicate the end of other discarded SDUs. SN_MRWi is the sequence number of the PDU that 
contains the LI of the i:th SDU to be discarded in the receiver (except for SN_MRW length when Nlength = 0, see 
definition of Nlength)- The order of the SN_MRWi shall be in the same sequential order as the SDUs that they refer to. 

Additionally SN_MRW length requests the RLC receiver to discard all PDUs with sequence number < 

SN_MRW LENGTH, and to move the receiving window accordingly. In addition, when Nlength > 0, the receiver has to 

discard the first Nlength Lis and the corresponding data octets in the PDU with sequence number SN_MRWlength- 

Nlength 

Length: 4 bits 

Nlength is used together with SN_MRW length to indicate the end of the last SDU to be discarded in the receiver. 

Nlength indicates which LI in the PDU with sequence number SN_MRWlength corresponds to the last SDU to be 
discarded in the receiver. Nlength = indicates that the last SDU ended in the PDU with sequence number 
SN_MRW LENGTH -1 and that the first data octet in the PDU with sequence number SN_MRW length is the first data 
octet to be reassembled next. 

9.2.2.12 Reserved 2 (R2) 

Length: 1 bit 

This bit in the Piggybacked STATUS PDU is used to achieve octet alignment and for this purpose it is coded as 0. 
Otherwise the PDU is treated as invalid and hence shall be discarded by this version of the protocol. 

9.2.2.1 3 Reset Sequence Number (RSN) 

Length: 1 bit 
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This field is used to indicate the sequence number of the transmitted RESET PDU. If this RESET PDU is a 
retransmission of the original RESET PDU then the retransmitted RESET PDU would have the same sequence number 
value as the original RESET PDU. Otherwise it will have the next reset sequence number. The initial value of this field 
is zero. The value of this field shall be reinitialised when the RLC is re-established. It shall not be reinitialised when the 
RLC is reset. 

9.2.2.14 Hyper Frame Number Indicator (HFNI) 

Length: 20 bit 

This field is used to indicate the hyper frame number (HFN) to the peer entity. With the aid of this field the HFN in UE 
and UTRAN can be synchronised. 

9.3 Protocol states 

9.3.1 State model for transparent mode entities 

Figure 9.16 illustrates the state model for transparent mode RLC entities (both transmitting and receiving). A 
transparent mode entity can be in one of following states. 

9.3.1.1 Null State 

In the null state the RLC entity does not exist and therefore it is not possible to transfer any data through it. 

Upon reception of a CRLC-CONFIG-Req from upper layer the RLC entity is created and transparent data transfer ready 
state is entered. 

9.3.1 .2 Transparent Data Transfer Ready State 

In the transparent data transfer ready, transparent mode data can be exchanged between the entities. Upon reception of a 
CRLC-CONFIG-Req from upper layer the RLC entity is terminated and the null state is entered. 

CRLC-CONFIG-Req 




Received signal 
CRLC-CONFIG-Req Sent signal 

Figure 9.16: The state model for transparent mode entities 

9.3.2 State model for unacknowledged mode entities 

Figure 9.17 illustrates the state model for unacknowledged mode RLC entities (both transmitting and receiving). An 
unacknowledged mode entity can be in one of following states. 

9.3.2.1 Null State 

In the null state the RLC entity does not exist and therefore it is not possible to transfer any data through it. 

Upon reception of a CRLC-CONFIG-Req from upper layer the RLC entity is created and unacknowledged data transfer 
ready state is entered. 
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9.3.2.2 



Unacknowledged Data Transfer Ready State 



In the unacknowledged data transfer ready, unacknowledged mode data can be exchanged between the entities. Upon 
reception of a CRLC-CONFIG-Req from upper layer the RLC entity is terminated and the null state is entered. 



9.3.2.3 



Local Suspend State 



Upon reception of a CRLC-SUSPEND-Req from upper layers the RLC entity is suspended and the Local Suspend state 
is entered. In the Local Suspend state RLC shall not send RLC-PDUs with SN>VT(US)+N. Upon reception of a CRLC- 
RESUME-Req from upper layers the RLC entity is resumed and the Data Transfer Ready state is entered. 



CRLC-CONFIG-Req 



CRLC-SUSPEND-Req 
CRbC-SUSPEND-Conf 




CRLC-CONFIG-Req 

3. 

Local 

Suspend J^ . , . , 
/Received signal 

Sent signal 



CRLC-CONFIG-Req 
Figure 9.17: The state model for unacknowledged mode entities 



9.3.3 State model for acknowledged mode entities 

Figure 9.18 illustrates the state model for the acknowledged mode RLC entity (both transmitting and receiving). An 
acknowledged mode entity can be in one of following states. 

9.3.3.1 Null State 

In the null state the RLC entity does not exist and therefore it is not possible to transfer any data through it. 

Upon reception of a CRLC-CONFIG-Req from upper layer indicating (re)establish, the RLC entity is created and the 
acknowledged data transfer ready state is entered. 

9.3.3.2 Acknowledged Data Transfer Ready State 

In the acknowledged data transfer ready state, acknowledged mode data can be exchanged between the entities. Upon 
reception of a CRLC-CONFIG-Req from upper layer indicating release, the RLC entity is terminated and the null state 
is entered. 

Upon errors in the protocol, the RLC entity sends a RESET PDU to its peer and enters the reset pending state. 

Upon reception of a RESET PDU, the RLC entity resets the protocol (see subclause 11. 4. 3), sets the hyper frame 
number HEN (DL HEN when the RESET is received in UE or UL HFN when the RESET is received in UTRAN) equal 
to the HFNI field in the RESET PDU and responds to the peer entity with a RESET ACK PDU. 

Upon reception of a RESET ACK PDU, the RLC takes no action. 

Upon reception of CRLC-SUSPEND-Req from upper layer, the RLC entity is suspended and the local suspend state is 
entered. 
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9.3.3.3 



Reset Pending State 



In the reset pending state the entity waits for a response from its peer entity and no data can be exchanged between the 
entities. Upon reception of a CRLC-CONFIG-Req from upper layer indicating release, the RLC entity is terminated and 
the null state is entered. 

Upon reception of a RESET ACK PDU with the same RSN value as in the corresponding RESET PDU, the RLC entity 
resets the protocol (see subclause 1 1 .4.4), sets the hyper frame number HEN (DL HEN when the RESET ACK is 
received in UE or UL HEN when the RESET ACK is received in UTRAN) equal to the HFNI field in the RESET ACK 
PDU and enters the acknowledged data transfer ready state. 

Upon reception of a RESET ACK PDU with a different RSN value as in the corresponding RESET PDU the RESET 
ACK PDU is discarded. 

Upon reception of a RESET PDU, the RLC entity resets the protocol (see subclause 11. 4. 3), sets the hyper frame 
number HEN (DL HEN when the RESET is received in UE or UL HEN when the RESET is received in UTRAN) equal 
to the HFNI field in the RESET PDU, sends a RESET ACK PDU and stays in the reset pending state. 

Upon reception of CRLC-SUSPEND-Req from upper layer, the RLC entity is suspended and the reset and suspend state 
is entered. 



CRLC-CONFIG-Req 




CRLC-CONFIG-Req 



Received signal 
Sent signal 



Figure 9.18: The state model for the acknowledged mode entities 



9.3.3.4 



Local Suspend State 



In the Local Suspend state RLC shall not send an RLC-PDUs with SN>VT(S)h-N, where VT(S) is the value of the send 
state variable when the CRLC-SUSPEND-Req with parameter N was received. Upon reception of CRLC-RESUME- 
Req from upper layers in this state, the RLC entity is resumed and the Acknowledged Data Transfer Ready state is 
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entered. Upon reception of CRLC-CONFIG-Req from upper layer indicating release, the RLC entity is terminated and 
the null state is entered. 

Upon errors in the protocol, the RLC entity sends a RESET PDU to its peer and enters the reset and suspend state. 

9.3.3.5 Reset and Suspend State 

In the reset and suspend state the entity waits for a response from its peer entity and no data can be exchanged between 
the entities. Upon reception of CRLC-CONFIG-Req from upper layer indicating release, the RLC entity is terminated 
and the null state is entered. 

Upon reception of a RESET ACK PDU with the same RSN value as in the corresponding RESET PDU, the RLC entity 
resets the protocol (see subclause 1 1 .4.4), sets the hyper frame number HFN (DL HFN when the RESET ACK is 
received in UE or UL HFN when the RESET ACK is received in UTRAN) equal to the HFNI field in the RESET ACK 
and enters the local suspend state. 

Upon reception of CRLC-RESUME-Req from upper layer in this state, the RLC entity is resumed and the reset pending 
state is entered. 

9.4 State variables 

This sub-clause describes the state variables used in the specification of the peer-to-peer protocol. All state variables are 
non-negative integers. PDUs are sequentially and independently numbered and may have the value through n minus 1 

19 7 

(where n is the modulus of the sequence numbers). The modulus equals 2^^ for AM and 2 for UM; the sequence 

numbers cycle through the entire range: through 2^^ - 1 for AM and through 2^-1 for UM. All arithmetic 
operations on the following state variables and sequence numbers contained in this specification are affected by the 
modulus: VT(S), VT(A), VT(MS), VR(R), VR(H), VR(MR), VT(US) and VR(US). When performing arithmetic 
comparisons of variables or SN values at the sender, VT(A) and VT(US) are assumed to be the base in AM and UM 
respectively. When performing arithmetic comparisons of variables or SN values at the receiver, VR(R) and VR(US) 
are assumed to be the base in AM and UM respectively. 

The RLC maintains the following state variables at the transmitter. 

a) VT(S) - Send state variable. 

The sequence number of the next PDU to be transmitted for the first time (i.e. excluding retransmission). It is 
updated after transmission of a PDU, which includes not earlier transmitted PDUs and after transmission of a 
MRW SUFI which includes SN_MRWlength >VT(S). The initial value of this variable is 0. 

b) VT(A) - Acknowledge state variable. 

The sequence number of the next in-sequence PDU expected to be acknowledged, which forms the lower edge 
of the window of acceptable acknowledgements. VT(A) is updated based on receipt of a STATUS PDU 
including an ACK and/or MRW_ACK super-field. The initial value of this variable is 0. 

c) VT(DAT). 

This state variable counts the number of times a PDU has been transmitted. There is one VT(DAT) for each 
PDU and it is incremented each time the PDU is transmitted. The initial value of this variable is 0. 

d) VT(MS) - Maximum Send state variable. 

The sequence number of the first PDU not allowed by the peer receiver [i.e. the receiver will allow up to 
VT(MS) - 1], VT(MS) = VT(A) + VT(WS). This value represents the upper edge of the transmit window. The 
transmitter shall not transmit a PDU with SN> VT(MS). VT(MS) is updated when either VT(A) or VT(WS) is 
updated. The PDU with SN VT(S)-1 can be transmitted also when VT(S) > VT(MS). 

e) VT(US) - UM data state variable. 

This state variable gives the sequence number of the next UMD PDU to be transmitted. It is updated each time a 
UMD PDU is transmitted. The initial value of this variable is 0. 

f) VT(PDU). 
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This state variable is used when the poll every Poll_PDU PDU function is used. It is incremented with 1 for each 
PDU that is transmitted. It should be incremented for both new and retransmitted PDUs. When it reaches 
Poll_PDU a new poll is transmitted and the state variable is set to zero. The initial value of this variable is 0. 

g) VT(SDU). 

This state variable is used when the poll every Poll_SDU SDU function is used. It is incremented with 1 for each 
SDU that is transmitted. When it reaches Poll_SDU a new poll is transmitted and the state variable is set to zero. 
The poll bit should be set in the PDU that contains the last segment of the SDU. The initial value of this variable 
isO. 

h) VT(RST) - Reset state variable. 

It is used to count the number of times a RESET PDU is transmitted. VT(RST) is incremented with 1 each time a 
RESET PDU is transmitted. VT(RST) is reset only upon the reception of a RESET ACK PDU, i.e. VT(RST) is 
not reset when an RLC reset occurs which was initiated from the peer RLC entity. The initial value of this 
variable is 0. 

i) VT(MRW) - MRW command send state variable. 

It is used to count the number of times a MRW command is transmitted. VT(MRW) is incremented with 1 each 
time an MRW command is transmitted. VT(MRW) is reset when the discard procedure is terminated. The initial 
value of this variable is 0. 

j) VT(WS) - Transmitter window size state variable. 

The size that shall be used for the transmitter window. VT(WS) is set equal to the WSN field when the 
transmitter receives a STATUS PDU including a Window Size super-field. The initial value of this variable is 
Configured_Tx_Window_size. 

The RLC maintains the following state variables at the receiver: 

a) VR(R) - Receive state variable. 

The sequence number of the next in-sequence PDU expected to be received. It is set equal to SNmax+1 upon 
receipt of the next in-sequence PDU, where SNmax is the sequence number of the highest received in-sequence 
PDU. The initial value of this variable is 0. 

b) VR(H) - Highest expected state variable. 

The sequence number of the highest expected PDU. This state variable is set equal to SNh-1 only when a new 
PDU is received with VR(MR)>SN>VR(H). The initial value of this variable is 0. 

c) VR(MR) - Maximum acceptable Receive state variable. 

The sequence number of the first PDU not allowed by the receiver [i.e. the receiver will allow up to VR(MR) - 
1], VR(MR) = VR(R) + Configured_Rx_Window_Size. The receiver shall discard PDUs with SN > VR(MR). 

d) VR(US) - Receiver Send Sequence state variable. 

The sequence number of the next PDU to be received. It shall set equal to SN + 1 upon reception of a PDU. The 
initial value of this variable is 0. 

e) VR(EP) - Estimated PDU Counter state variable. 

The number of PDUs that should be received yet as a consequence of the transmission of the latest status report. 
In acknowledged mode, this state variable is updated at the end of each transmission time interval. It is 
decremented by the number of PDUs that should have been received during the transmission time interval. If 
VR(EP) is equal to zero, then check if all PDUs requested for retransmission in the latest status report have been 
received. 

9.5 Timers 

a) Timer_Poll. 
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This timer is only used when the poll timer trigger is used. It is started when the successful or unsuccessful 
transmission of a PDU containing a poll is indicated by lower layer (in UE) or a PDU containing a poll is 
submitted to lower layer (in UTRAN). The timer is stopped when receiving a STATUS PDU that contains an 
acknowledgement of all AMD PDUs with SN up to and including VT(S)-1 at the time the poll was submitted to 
lower layer, or when a negative acknowledgement of the same PDU is received. The value of the timer is 
signalled by upper layers. 

If the timer expires and no STATUS PDU fulfilling the criteria above has been received, the receiver is polled 
once more (either by the transmission of a PDU which was not yet sent, or by a retransmission) and the timer is 
restarted at the time specified above, with a new value of VT(S)-1. 

If a new poll is sent when the timer is running the timer is restarted at the time specified above, with a new value 
ofVT(S)-l. 

b) Timer_Poll_Prohibit. 

This timer is only used when the poll prohibit function is used. It is used to prohibit transmission of polls within 
a certain period. The timer shall be started when the successful or unsuccessful transmission of a PDU 
containing a poll is indicated by lower layer (in UE) or a PDU containing a poll is submitted to lower layer (in 
UTRAN). The prohibit time is calculated from the time a PDU containing a poll is submitted to lower layer until 
the timer has expired. A poll shall be delayed until the prohibit time expires if a poll is triggered during the 
prohibit time. Only one poll shall be transmitted when the prohibit time expires even if several polls were 
triggered during the prohibit time. This timer will not be stopped by a received STATUS PDU. The value of the 
timer is signalled by upper layers. 

c) Timer_EPC. 

This timer is only used when the EPC function is used and it accounts for the roundtrip delay, i.e. the time when 
the first retransmitted PDU should be received after a status report has been sent. The timer is started when the 
successful or unsuccessful transmission of the first STATUS PDU of a status report is indicated by lower layer 
(in UE) or the first STATUS PDU of a status report is submitted to lower layer (in UTRAN) and when it expires 
VR(EP) can start its counting-down process (see subclause 9.7.4). The value of the timer is signalled by upper 
layers. 

d) Timer_Discard. 

This timer is used for the SDU discard function. In the transmitter, the timer is activated upon reception of an 
SDU from upper layer. One timer is used for each SDU that is received from upper layer. For UM/Tr, if the 
timer expires before the SDU is submitted to a lower layer, "SDU discard without explicit signalling" specified 
in subclauses 1 1 .2.4.3/1 1 . 1 .4.2 shall be started. For AM, if the timer expires before the SDU is acknowledged, 
"SDU discard with explicit signalling" specified in subclause 1 1.6 shall be started. 

e) Timer_Poll_Periodic. 

This timer is only used when the timer based polling is used. The timer is started when the RLC entity is created. 
Each time the timer expires, the timer is restarted and a poll is triggered (either by the transmission of a PDU 
which was not yet sent, or by a retransmission). If there is no PDU to be transmitted and all PDUs have already 
been acknowledged, a poll shall not be triggered and the timer shall only be restarted. The value of the timer is 
signalled by upper layers. 

f) Timer_Status_Prohibit. 

This timer is only used when the STATUS prohibit function is used. It prohibits the receiving side from sending 
status reports containing any of the SUFIs LIST, BITMAP, RLIST or ACK. The timer is started when the 
successful or unsuccessful transmission of the last STATUS PDU in a status report is indicated by lower layer 
(in UE) or the last STATUS PDU in a status report is submitted to lower layer (in UTRAN). The prohibit time is 
calculated from the time the last STATUS PDU of a status report is submitted to lower layer until the timer has 
expired and no new status report containing the mentioned SUFIs can be transmitted during the prohibit time. 
The timer does not prohibit transmission of the SUFIs MRW, MRW_ACK, WINDOW or NO_MORE. The 
value of the timer is signalled by upper layers. 

g) Timer_Status_Periodic. 

This timer is only used when timer based status report sending is used. The timer is started when the RLC entity 
is created. Each time the timer expires the transmission of a status report is triggered and the timer is restarted. 
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The value of the timer is signalled by upper layers. This timer can be blocked by upper layers. In this case, the 
timer shall not be active. The timer shall be reset and restarted when it is unblocked by upper layers. 

h) Timer_RST. 

This timer is used to detect the loss of RESET ACK PDU from the peer RLC entity. This timer is started when 
the successful or unsuccessful transmission of a RESET PDU is indicated by lower layer (in UE) or a RESET 
PDU is submitted to lower layer (in UTRAN). It will only be stopped upon reception of RESET ACK PDU, i.e. 
this timer is not stopped when an RLC reset occurs which was initiated from the peer RLC entity. If it expires, 
RESET PDU will be retransmitted. The value of the timer is signalled by upper layers. 

i) Timer_MRW. 

This timer is used as part of the Move Receiving Window protocol. It is used to trigger the retransmission of a 
status report containing an MRW SUFI field. The timer is started when the successful or unsuccessful 
transmission of a STATUS PDU containing the MRW SUFI is indicated by lower layer (in UE) or a STATUS 
PDU containing the MRW SUFI is submitted to lower layer (in UTRAN). Each time the timer expires the MRW 
SUFI is retransmitted and the timer is restarted (at the time specified above). It shall be stopped when one of the 
termination criteria for the SDU discard is fulfilled. The value of the timer is signalled by upper layers. 

9.6 Protocol Parameters 

The values of the protocol parameters in this subclause are signalled by upper layers. 

a) MaxDAT. 

It is the maximum value for the number of retransmissions of a PDU. This parameter is an upper limit of counter 
VT(DAT). When the value of VT(DAT) comes to MaxDAT, either RLC RESET procedure or SDU discard 
procedure shall be initiated according to configuration by upper layer. 

b) PolLPDU. 

This parameter indicates how often the transmitter should poll the receiver in case of polling every Poll_PDU 
PDU. This is an upper limit for the VT(PDU) state variable, when VT(PDU) reaches Poll_PDU a poll is 
transmitted to the peer entity. 

c) PolLSDU. 

This parameter indicates how often the transmitter should poll the receiver in case of polling every Poll_SDU 
SDU. This is an upper limit for the VT(SDU) state variable, when VT(SDU) reaches Poll_SDU a poll is 
transmitted to the peer entity. 

d) PolLWindow. 

This parameter indicates when the transmitter should poll the receiver in case of performing window-based 
polling. The range of values of this parameter shall be < Poll_Window < 100. A poll is triggered for each PDU 
when J > Poll_Window, where J is the window transmission percentage defined by 

(4096+VT(S) - VT(A)) mod 4096 

J= * 100 

VT(WS) '^^^ ' 

where the constant 4096 is the modulus for AM described in Subclause 9.4. e) MaxRST. 

It is the maximum value for the number of retransmission of RESET PDU. This parameter is an upper limit of 
counter VT(RST). When the value of VT(RST) comes to MaxRST, unrecoverable error shall be indicated to 
upper layer. 

f) Configured_Tx_Window_Size. 

The maximum allowed transmitter window size. 

g) Configured_Rx_Window_Size. 
The allowed receiver window size. 
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h) MaxMRW. 

It is the maximum value for the number of retransmissions of a MRW command. This parameter is an upper 
limit of counter VT(MRW). When the value of VT(MRW) comes to MaxMRW, RLC RESET procedure shall be 
initiated. 

9.7 Specific functions 

9.7.1 Polling function for acknowledged mode 

The transmitter of AMD PDUs may poll the receiver for a status report (consisting of one or several STATUS PDUs). 
The Polling bit in the AMD PDU indicates the poll request. If there is no PDU to be transmitted and all PDUs have 
already been acknowledged, the receiver shall not be polled. There are several triggers for setting the polling bit. Upper 
layers control, which triggers should be used for each RLC entity. Following triggers are possible: 

1) Last PDU in buffer. 

The sender triggers a poll when the last PDU available for transmission is transmitted. 

2) Last PDU in retransmission buffer. 

The sender triggers a poll when the last PDU to be retransmitted is transmitted. 

3) Poll timer. 

The timer Timer_Poll is started when the successful or unsuccessful transmission of a PDU containing a poll is 
indicated by lower layer (in UE) or a PDU containing a poll is submitted to lower layer (in UTRAN) and if the 
criterion for stopping the timer has not occurred before the timer Timer_Poll expires a new poll is triggered. 

4) Every PolLPDU PDU. 

The sender triggers a poll every Poll_PDU PDU. Both retransmitted and new PDUs shall be counted. 

5) Every PolLSDU SDU. 

The sender triggers a poll every Poll_SDU SDU. 

6) Window based. 

The sender triggers a poll when it has reached Poll_Window% of the transmission window. 

7) Timer based. 

The sender triggers a poll periodically. 

Either the trigger "Last PDU in buffer" and "Last PDU in retransmission buffer" or "Timer based" can be chosen to 
avoid deadlock for every RLC entity. The network also controls if the poll prohibit function shall be used. The poll bit 
shall be set to if the poll prohibit function is used and the timer Timer_Poll_Prohibit is active. If a poll was triggered 
during the prohibit time defined in subclause 9.5 b) (Timer_Poll_Prohibit), the poll shall be delayed until the timer 
expires. Only one poll shall be transmitted when the timer expires even if several polls were triggered during the 
prohibit time. This function has higher priority than any of the above-mentioned triggers. 

9.7.2 STATUS transmission for acknowledged mode 

The receiver of AMD PDUs transmits status reports (each status report consists of one or several STATUS PDUs) to 
the sender in order to inform about which PDUs that have been received and not received. There are several triggers for 
sending a status report. Upper layers control which triggers should be used for each RLC entity, except for one, which is 
always present. The receiver shall always send a status report when receiving a poll request. Except for that trigger 
following triggers are configurable: 

1) Detection of missing PDU(s). 
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If the receiver detects one or several missing PDUs it shall trigger the transmission of a status report to the 
sender. 

2) Timer based STATUS transfer. 

The receiver triggers the transmission of a status report periodically to the sender. The timer 
Timer_Status_Periodic controls the time period. When Periodical Status blocking is configured by upper layer, 
the trigger shall not be active. 

3) The EPC mechanism. 

The timer Timer_EPC is started and the state variable VR(EP) is set when the successful or unsuccessful 
transmission of the first STATUS PDU of a status report is indicated by lower layer (in UE) or the first STATUS 
PDU of a status report is submitted to lower layer (in UTRAN). If not all PDUs requested for retransmission 
have been received before the variable VR(EP) has reached zero, a new status report is transmitted to the peer 
entity. A more detailed description of the EPC mechanism is given in subclause 9.7.4. 

There are two functions that can prohibit the receiver from sending a status report. Upper layers control which functions 
should be used for each RLC entity. If any of the following functions is used the sending of the status report shall be 
delayed, even if any of the triggering conditions above are fulfilled: 

1) STATUS prohibit. 

The Timer_Status_Prohibit is started when the successful or unsuccessful transmission of the last STATUS PDU 
of a status report is indicated by lower layer (in UE) or the last STATUS PDU of a status report is submitted to 
lower layer (in UTRAN). The prohibit time is calculated from the time the last STATUS PDU of a status report 
is submitted to lower layer until the timer has expired. The receiving side is not allowed to transmit a status 
report during the prohibit time. If a status report was triggered during the prohibit time, the status report is 
transmitted after the prohibit time has expired. The receiver shall only send one status report, even if there are 
several triggers during the prohibit time. This timer only prohibits the transmission of status reports containing 
any of the SUFIs LIST, BITMAP, RLIST or ACK. Status reports containing other SUFIs are not prohibited. 

2) The EPC mechanism. 

If the EPC mechanism is active and the sending of a status report is triggered it shall be delayed until the EPC 
mechanism has ended. The receiver shall only send one status report, even if there are several triggers when the 
timer is active or the counter is counting down. This mechanism only prohibits the transmission of status reports 
containing any of the SUFIs LIST, BITMAP, RLIST or ACK. Status reports containing other SUFIs are not 
prohibited. 

9.7.3 SDU discard function for acknowledged, unacknowledged, and 
transparent mode 

The SDU discard function allows to discharge RLC PDU from the buffer on the transmitter side, when the transmission 
of the RLC PDU does not success for a long time. The SDU discard function allows to avoid buffer overflow. There 
will be several alternative operation modes of the RLC SDU discard function. Upper layers control, which discard 
function shall be used for each RLC entity. 

The following is a list of operation modes for the RLC SDU discard function. 

Table 9.2: List of criteria that control when to perform SDU discard 



Operation mode 


Presence 


Timer based discard, with explicit signalling 


Network controlled 


Timer based discard, without explicit signalling 


Network controlled 


SDU discard after MaxDAT number of retransmissions 


Network controlled 


No discard after MaxDAT number of retransmissions 


Network controlled 
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9.7.3.1 Timer based discard, with explicit signalling 

This alternative uses a timer based triggering of SDU discard (Timer_Discard). This makes the SDU discard function 
insensitive to variations in the channel rate and provides means for exact definition of maximum delay. However, the 
SDU loss rate of the connection is increased as SDUs are discarded. 

For every SDU received from a upper layer, timer monitoring of the transmission time of the SDU is started. If the 
transmission time exceeds a predefined value for an SDU in acknowledged mode RLC, this SDU is discarded in the 
transmitter. Following which, if one or more segments of the SDU have been submitted to a lower layer, a Move 
Receiving Window (MRW) command is sent to the receiver so that AMD PDUs carrying that SDU are discarded in the 
receiver and the receiver window is updated accordingly. If Send MRW is configured, an expired SDU whose segments 
were not submitted to a lower layer is also informed to the receiver by a MRW command. 

NOTE: When the concatenation function is active, PDUs carrying segments of other SDUs that have not timed 
out shall not be discarded. 

The MRW command is defined as a super-field in the RLC STATUS PDU (see subclause 9.2), and piggybacked to 
status information of transmissions in the opposite direction. If the MRW command has not been acknowledged by 
receiver, it will be retransmitted. Therefore, SDU discard variants requiring peer-to-peer signalling are only possible for 
full duplex connections. 

9.7.3.2 Timer based discard, without explicit signalling 

This alternative uses the same timer based trigger for SDU discard (Timer_Discard) as the one described in the 
subclause 9.7.3.1. The difference is that this discard method does not use any peer-to-peer signalling. This function is 
applied only for unacknowledged and transparent mode RLC and peer-to-peer signalling is never needed. The SDUs are 
simply discarded in the transmitter, once the transmission time is exceeded. For UM RLC, how to update the sequence 
number is specified in subclause 11. 2.4. 3. 

9.7.3.3 SDU discard after MaxDAT number of retransmissions 

This alternative uses the number of retransmissions as a trigger for SDU discard, and is therefore only applicable for 
acknowledged mode RLC. This makes the SDU discard function dependent of the channel rate. Also, this variant of the 
SDU discard function strives to keep the SDU loss rate constant for the connection, on the cost of a variable delay. SDU 
discard is triggered at the transmitter, and a MRW command is necessary to convey the discard information to the 
receiver, like in the timer-based discard with explicit signalling. 

9.7.3.4 No_discard after MaxDAT number of retransmissions 

This alternative uses the number of retransmissions, and is therefore only applicable for acknowledged mode RLC. 
Reset procedure shall be initiated after MaxDAT number of retransmissions of an AMD PDU (see subclause 11. 3. 4.4). 

9.7.3.5 SDU discard not configured 

If SDU discard has not been configured for an unacknowledged mode RLC entity, SDUs in the transmitter shall not be 
discarded unless the transmission buffer is full. If the transmission buffer is full, SDUs may be discarded using SDU 
discard without explicit signalling. If no segments of the SDU has been transmitted, the SDU may be removed from the 
buffer without using any of the SDU discard procedures. 

If SDU discard has not been configured for a transparent mode RLC entity, SDUs in the transmitter shall be transmitted 
in the first possible TTI and other not yet transmitted SDUs received from upper layer in previous TTIs shall be 
discarded upon reception of a new SDU from upper layer. 

For an acknowledged mode RLC entity, an SDU discard mode is always configured. 

9.7.4 The Estimated PDU Counter for acknowledged mode 

The Estimated PDU Counter is a mechanism used for scheduling the retransmission of status reports in the receiver 
side. With this mechanism, the receiver will send a new status report in which it requests for PDUs not yet received. 
The time between two subsequent status report retransmissions is not fixed, but it is controlled by both the timer 
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Timer_EPC and the state variable VR(EP), which adapt this time to the round trip delay and the current bit rate, 
indicated in the TFI, in order to minimise the delay of the status report retransmission. 

When a STATUS report is triggered by some mechanisms and it is submitted to lower layer (in UTRAN) or the 
successful or unsuccessful transmission of it is indicated by lower layer (in UE) to request for retransmitting one or 
more missing PDUs, the variable VR(EP) is set equal to the number of requested PDUs. At least one requested PDU is 
needed to activate the EPC mechanism. The variable VR(EP) is a counter, which is decremented every transmission 
time interval with the estimated number of PDUs that should have been transmitted during that transmission time 
interval. 

A special timer, called Timer_EPC, controls the maximum time that the variable VR(EP) needs to wait before it will 
start counting down. This timer starts immediately after a transmission of a retransmission request from the receiver 
(when the first STATUS PDU of the status report is submitted to lower layer (in UTRAN) or the successful or 
unsuccessful transmission of it is indicated by lower layer(in UE)). The timer Timer_EPC typically depends on the 
roundtrip delay, which consists of the propagation delay, processing time in the transmitter and receiver and the frame 
structure. This timer can also be implemented as a counter, which counts the number of 10 ms radio frames that could 
be expected to elapse before the first requested AMD PDU is received. 

If not all of these requested PDUs have been received correctly when VR(EP) is equal to zero, a new status report will 
be transmitted and the EPC mechanism will be reset accordingly. The timer Timer_EPC will be started once more when 
the first STATUS PDU of the status report is submitted to lower layer (in UTRAN) or the successful or unsuccessful 
transmission of it is indicated by lower layer (in UE). If all of the requested PDUs have been received correctly, the 
EPC mechanism ends. 

9.7.5 Local Suspend function for acknowledged and unacknowledged 
mode 

The upper layers may suspend the RLC entity. The CRLC-SUSPEND-Req indicates this request. The RLC entity shall, 
when receiving this request, not send RLC PDUs with SN>VT(S)+N for AM and SN>VT(US)+N for UM ,where N is 
given by the CRLC_SUSPEND-Req primitive. The RLC entity shall acknowledge the CRLC-SUSPEND-Req ordering 
a suspend with a CRLC-SUSPEND-Conf with the current value of VT(S) for AM and VT(US) for UM. When a CRLC- 
RESUME-Req primitive indicating resume is received, the AM RLC entity enters the acknowledged data transfer ready 
state if it is in the local suspend state and enters the reset pending state if it is in the reset and suspend state. 

9.7.6 RLC Stop, RLC Continue function for acknowledged and 
unacknowledged mode 

The upper layer may stop the RLC entity. The stop parameter in the CRLC-CONFIG-Req primitive indicates this 
request. The RLC entity shall, when receiving this request, not submit any RLC PDUs to lower layer or receive any 
RLC PDUs. The data transmission and reception is continued when the continue parameter in the CRLC-CONFIG-Req 
primitive is received. If the continue parameter is received when the RLC entity is not stopped, no action shall be taken. 

When the RLC entity is stopped, the RLC timers are not affected. Triggered polls and status transmissions are delayed 
until the RLC entity is continued. 

9.7.7 RLC re-establishment function for acknowledged and 
unacknowledged mode 

The RLC re-establishment function is applicable for AM and UM and is used when upper layers request the RLC entity 
to be re-established. 

When an RLC entity is re-established, the state variables in the RLC entity (see 9.4) shall be reset to their initial value 
and the configurable parameters shall be set to their configured value. In AM, all RLC PDUs in the RLC receiver and 
transmitter shall be discarded. In UM, the RLC SDU for which one or more segments have been submitted to a lower 
layer in the transmitter shall be discarded. The hyper frame number (HEN) in UL and DL shall be set to the value 
configured by upper layers. After the re-establishment, RLC shall enter the data transfer ready state. 
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9.7.8 Ciphering for acl^nowledged and unacl<nowledged mode 

The ciphering function is performed in RLC, according to the following rules if a radio bearer is using a non-transparent 
RLC mode (AM or UM). The data unit that is ciphered, depends on the transmission mode as described below. 

For RLC UM mode, the ciphering unit is the UMD PDU excluding the first octet, i.e. excluding the RLC UMD 
PDU header. This is shown below in Figure 9.19. 
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Figure 9.19: Ciphering unit for a UIVID PDU 

For RLC AM mode, the ciphering unit is the AMD PDU excluding the first two octets, i.e. excluding the RLC 
AMD PDU header. This is shown below in Figure 9.20. 
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Figure 9.20: Ciphering unit for an AIVID PDU 

The ciphering algorithm and key to be used are configured by upper layers [8] and the ciphering method shall be 
applied as specified in [10]. 

The parameters that are required by RLC for ciphering are defined in [10] and are input to the ciphering algorithm. The 
parameters required by RLC which are provided by upper layers [8] are listed below: 

RLC AM HFN (Hyper frame number for radio bearers that are mapped onto RLC AM) 

RLC UM HFN (Hyper frame number for radio bearers that are mapped onto RLC UM) 

- BEARER (Radio Bearer ID) 

- CK (Ciphering Key) 
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10 Handling of unknown, unforeseen and erroneous 
protocol data 

In case of error situations the following actions are foreseen: 

1) RLC entity shall initiate RESET procedure in case of a protocol error. 

2) RLC entity shall discard invalid PDUs. 

3) RLC entity shall notify upper layer of unrecoverable error occurrence (see subclause 1 1.4.5.2). 
The list of protocol error cases is reported below: 

Inconsistent state variables; 

If the RLC entity receives a PDU including "erroneous Sequence Number", state variables between peer entities 
may be inconsistent. Following shows "erroneous Sequence Number" examples: 

- Each Sequence Number of missing PDU informed by SUFI LIST, BITMAP or RLIST is not within the value 
between "Acknowledge state variable(VT(A))" and "Send state variable(VT(S)) - 1", and 

- LSN of SUFI ACK is not within the value between "Acknowledge state variable(VT(A))" and "Send state 
variable(VT(S))". 

Inconsistent status indication of a PDU; 

If a received STATUS PDU indicates different status for the same PDU, then the transmitter shall discard the 
STATUS PDU. 

Invalid PDU format; 

If the RLC PDU format contains reserved or invalid values, the RLC PDU shall be discarded. 



1 1 Elementary procedures 

11.1 Transparent mode data transfer procedure 
11.1.1 Purpose 

The transparent mode data transfer procedure is used for transferring of data between two RLC peer entities, which are 
operating in transparent mode. Figure H . 1 below illustrates the elementary procedure for transparent mode data 
transfer. The sender can be either the UE or the network and the receiver is either the network or the UE. 



Sender 



Receiver 



TrD PDU 



Figure 11 .1 : Transparent mode data transfer procedure 

11.1.2 Initiation 

The sender initiates this procedure upon a request of transparent mode data transfer from upper layer. When the sender 
is in data transfer ready state it shall put the data received from the upper layer into TrD PDUs. If required RLC shall 
perform segmentation. 
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Channels that can be used are DTCH, CCCH (upHnk only), SHCCH (upHnk only), BCCH and PCCH. The type of 
logical channel depends on if the RLC entity is located in the user plane (DTCH) or in the control plane 
(CCCH/BCCH/SHCCH/PCCH). One or several PDUs may be transmitted in each transmission time interval (TTI). For 
each TTI, MAC decides which PDU size shall be used (applicable when segmentation is used) and how many PDUs 
shall be transmitted. The SDUs that cannot be transmitted in a TTI shall be buffered according to the discard 
configuration set by upper layers. 

If timer based SDU discard is used, the timer Timer_Discard shall be started when the RLC entity receives an SDU 
from upper layer. One timer is used for each SDU that is received from upper layer. 

11.1.2.1 TrD PDU contents to set 

The TrD PDU includes a complete SDU or a segment of an SDU. How to perform the segmentation is decided upon 
when the service is established. No overhead or header is added, instead segmentation is done based on which of the 
transport formats of the transport channel that will be used. A particular transport format informs the receiver how the 
segmentation was performed. 

11.1.3 Reception of TrD PDU 

Upon reception of a TrD PDU, the receiving entity reassembles (if segmentation was performed) the PDUs into RLC 
SDUs. RLC delivers the RLC SDUs to the upper layer through the Tr-SAP. 

If delivery of erroneous SDUs is configured as 'yes' by an upper layer, the receiver shall deliver an erroneous SDU to 
upper layer with an error indication. If delivery of erroneous SDUs is configured as 'no' by an upper layer the receiver 
shall discard the erroneous SDU. If delivery of erroneous SDUs is configured as 'No detect' by an upper layer, all SDUs 
shall be delivered to upper layer without error indication. 

If segmentation is performed in transparent mode RLC, an SDU is erroneous if one or more of the TrD PDUs received 
in a TTI contains an error. If segmentation is not performed, an SDU is erroneous if the corresponding TrD PDU is 
erroneous. 

11.1.4 Abnormal cases 

11.1.4.1 Void 

11.1 .4.2 SDU discard without explicit signalling 

Upon expiry of the Timer_Discard on the sender side the sender shall discard the associated SDU. In the case where the 
TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the UE may wait until 
after it provides MAC with the requested set of PDUs before discarding the afore-mentioned SDU. 

1 1 .2 Unacknowledged mode data transfer procedure 
11.2.1 Purpose 

The unacknowledged mode data transfer procedure is used for transferring data between two RLC peer entities, which 
are operating in unacknowledged mode. Figure U .2 below illustrates the elementary procedure for unacknowledged 
mode data transfer. The sender can be either the UE or the network and the receiver is either the network or the UE. 
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Sender 



Receiver 



UMD PDU 



Figure 11.2: Unacknowledged mode data transfer procedure 

11.2.2 Initiation 

The sender initiates this procedure upon a request of unacknowledged mode data transfer from upper layer. 

When the sender is in data transfer ready state it shall segment and, if possible, concatenate the data received from the 
upper layer into PDUs. 

Channels that can be used are DTCH, DCCH, CCCH (downlink only), CTCH, SHCCH (downlink only). The type of 
logical channel depends on if the RLC entity is located in the user plane (DTCH, CTCH) or in the control plane 
(DCCH/CCCH(downlink only)/SHCCH(downlink only)). One or several PDUs may be transmitted in each 
transmission time interval (TTI). For each TTI, MAC decides which PDU size shall be used and how many PDUs shall 
be transmitted. 

The VT(US) state variable shall be updated for each UMD PDU that is transmitted. 

If timer based SDU discard is used, the timer Timer_Discard shall be started when the RLC entity receives an SDU 
from upper layers. One timer is used for each SDU that is received from upper layers. 

A UMD PDU will be considered to be a padding PDU if it consists only of an RLC Header with one length indicator 
(indicating that the rest of the PDU is padding) and padding. 

11.2.2.1 UMD PDU contents to set 

The Sequence Number field shall be set equal to VT(US). 

The Extension bit shall be set to 1 if the next field is a length indicator field, otherwise it shall be set to zero. 

One length indicator field shall be included for each end of an SDU that the PDU includes. The LI fields shall be set as 
specified in subclause 9.2.2.8. 

1 1 .2.3 Reception of UMD PDU 

Upon reception of a UMD PDU, the receiver shall update VR(US) state variable according to the received PDU(s). 

The PDUs are reassembled into RLC SDUs. If the updating step of the variable VR(US) is greater than one, one or 
more PDUs are missing. The SDUs that have segments in these missing PDUs shall be discarded. RLC delivers the 
RLC SDUs to the upper layers through the UM-SAP. 

1 1 .2.4 Abnormal cases 

1 1 .2.4.1 Length Indicator value reserved for UMD PDU 

Upon reception of an UMD PDU that contains Length Indicator value reserved for UMD PDU, the receiver shall 
discard that UMD PDU. 



11.2.4.2 



Invalid length indicator value 



If the length indicator of a PDU has a value that is larger than the PDU size - RLC header size and is not one of the 
predefined values listed in the table of subclause 9.2.2.8, the PDU shall be discarded and treated as a missing PDU. 
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1 1 .2.4.3 SDL) discard without explicit signalling 

Upon expiry of the Timer_Discard on the sender side the sender shall discard the associated SDU. In the case where the 
TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the UE may wait until 
after it provides MAC with the requested set of PDUs before discarding the afore-mentioned SDU. For UM RLC, SN of 
the UMD PDUs shall be incremented by a step of 2 for the first PDU transmitted after a Discard Operation to indicate 
that there were some RLC SDUs discarded before this RLC PDU. The first data octet in this RLC PDU shall be the first 
octet of an RLC SDU. To prevent the receiver from discarding one extra SDU, an LI field shall be added in the first 
PDU transmitted after a Discard Operation. The value of the LI field shall be the value indicating that the previous SDU 
filled exactly the previous RLC PDU. 

1 1 .3 Acknowledged mode data transfer procedure 
11.3.1 Purpose 

The acknowledged mode data transfer procedure is used for transferring of data between two RLC peer entities, which 
are operating in acknowledged mode. Figure 11.3 below illustrates the elementary procedure for acknowledged mode 
data transfer. The sender can be either the UE or the network and the receiver is either the network or the UE. 



Sender 



Receiver 



AMD PDU 



Figure 11.3: Acltnowledged mode data transfer procedure 

11.3.2 Initiation 

The sender initiates this procedure upon a request of acknowledged mode data transfer from upper layers or upon 
retransmission of PDUs. Retransmitted PDUs have higher priority than PDUs transmitted for the first time. 

The sender is only allowed to retransmit PDUs that have been indicated missing by the receiver. An exception is the 
PDU with SN VT(S)-1, which can be retransmitted. In addition, a PDU that has not yet been acknowledged, may be 
retransmitted if Configured_Tx_Window_Size is less than 2048. 

RLC shall segment the data received from the upper layers into AMD PDUs. The PDUs shall be transmitted on the 
DCCH logical channel if the sender is located in the control plane and on the DTCH if it is located in the user plane. 
One or several PDUs may be transmitted in each transmission time interval (TTI) and MAC decides how many PDUs 
shall be transmitted in each TTI. In the UE, the PDUs that cannot be transmitted in a TTI (i.e. MAC has indicated that 
some of the available PDUs can not be transmitted) shall be buffered according to the discard configuration set by upper 
layers. 

The VT(DAT) state variables shall be updated for each AMD PDU that is transmitted. The PDU shall not have a 
Sequence Number > VT(MS), except for the sequence number VT(S)-1; a PDU with this sequence number may be sent 
also when VT(S) > VT(MS). 

If the poll bit is set in any of the AMD PDUs and the timer Timer_Poll shall be used, the sender shall start the timer 
Timer_Poll when the successful or unsuccessful transmission of a PDU with the set poll bit is indicated by lower layer 
(in UE) or submitted to lower layer (in UTRAN). 

If timer based SDU discard is used, the timer Timer_Discard shall be started when the RLC entity receives an SDU 
from upper layers. One timer is used for each SDU that is received from upper layers. 

If the trigger for polHng, "Every Poll_PDU PDU", is used, the VT(PDU) shall be increased by 1 for each PDU that is 
transmitted. 
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If the trigger for polling, "Every Poll_SDU SDU", is used, the VT(SDU) shall be increased by 1 for each SDU that is 
transmitted. 

In AM, a PDU will be considered to be a padding PDU if it is: 

- An AMD PDU consisting only of an RLC Header with one length indicator (indicating that the rest of the PDU 
is padding) and padding. 

- A Status PDU consisting only of a NO_MORE SUFI. 

11.3.2.1 AMD PDU contents to set 

If the PDU is transmitted for the first time, the Sequence Number field shall be set equal to VT(S) and VT(S) shall be 
updated. 

The setting of the Polling bit is specified in subclause 11.3.2.1.1. 

One length indicator field shall be included for each end of an SDU that the PDU includes. The LI fields shall be set as 
specified in subclause 9.2.2.8. 

How to perform the segmentation and concatenation of SDUs is specified in subclause 1 1 .3.2. 1 .2. 

1 1 .3.2.1 .1 Setting of the Polling bit 

The Polling bit shall be set to 1 if any of following conditions are fulfilled except when the poll prohibit function is 
used and the timer Timer_Poll_Prohibit is active (the different triggers are described in 9.7.1): 

1) Last PDU in buffer is used and the last PDU available for transmission is transmitted. 

2) Last PDU in retransmission buffer is used and the last PDU to be retransmitted is transmitted. 

3) Poll timer is used and timer Timer_Poll has expired. 

4) Every Poll_PDU PDU is used and when VT(PDU)=Poll_PDU. 

5) Every Poll_SDU is used and VT(SDU)=Poll_SDU and the PDU contains the last segment of that SDU. 

6) Window based polling is used, and J > Poll_Window, where J is defined in subclause 9.6. 

7) Timer based polling is used and Timer_Poll_Periodic has expired. 

8) Poll prohibit shall be used, the timer Timer_Poll_Prohibit has expired and one or several polls were prohibited 
during the time Timer_Poll_Prohibit was active. 

1 1 .3.2.1 .2 Segmentation and concatenation of SDUs 

Upon reception of an SDU, RLC shall segment the SDU to fit into the fixed size of a PDU. The segments are inserted in 
the data field of a PDU. A length indicator shall be added to each PDU that includes a border of an SDU, i.e. if a PDU 
does not contain an LI, the SDU continues in the next PDU. The length indicator indicates where the border occurs in 
the PDU. The data after the indicated border can be either a new SDU, padding or piggybacked information. If padding 
or piggybacking is added another LI shall be added unless the padding size is one octet for PDUs with 15-bit Lis, see 
subclauses 9.2.2.8 and 9.2.2.9. 

1 1 .3.3 Reception of AMD PDU by the receiver 

Upon reception of an AMD PDU, the receiver shall update VR(R), VR(H) and VR(MR) state variables according to the 
received PDU. 

If a received PDU includes a Polling bit set to 1, the STATUS PDU transfer procedure shall be initiated. 

If the detection of missing PDU(s) shall be used and the receiver detects that a PDU is missing, the receiver shall 
initiate the STATUS PDU transfer procedure. 
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1 1 .3.4 Abnormal cases 

11.3.4.1 Timer_Poll timeout 

Upon expiry of the Timer_Poll, the sender shall retransmit the poll. The poll can be retransmitted in either a new PDU 
or a retransmitted PDU. 

1 1 .3.4.2 Receiving a PDU outside the receiving window 

Upon reception of a PDU with sequence number outside the interval VR(R)<SN<VR(MR), the receiver shall discard 
the PDU. The poll bit shall be considered even if a complete PDU is discarded. 

1 1 .3.4.3 Timer_Discard timeout 

1 1 .3.4.3.1 SDU discard with explicit signalling 

Upon expiry of Timer_Discard, the sender shall initiate the SDU discard with explicit signalling procedure. In the case 
where the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the UE may 
wait until after it provides MAC with the requested set of PDUs before discarding the afore-mentioned SDU. 

1 1 .3.4.4 VT(DAT) > MaxDAT 

If SDU discard after MaxDAT number of retransmission is used and VT(D AT) > MaxDAT for any PDU, the sender 
shall initiate the SDU discard with explicit signalling procedure. All the SDUs that have segments in PDUs with 
sequence numbers inside the interval VT(A) < SN < SN of the PDU with VT(DAT) > MaxDAT shall be discarded. 

If No_discard after MaxDAT number of retransmissions is used, the sender shall initiate the RLC reset procedure when 
VT(DAT) > MaxDAT. 

1 1 .3.4.5 Invalid length indicator value 

If the length indicator of a PDU has a value that is larger than the PDU size - RLC header size and is not one of the 
predefined values listed in the table of subclause 9.2.2.8, the PDU shall be discarded and treated as a missing PDU. 

1 1 .3.4.6 Length Indicator value reserved for AMD PDU 

Upon reception of an AMD PDU that contains Length Indicator value reserved for AMD PDU, the receiver shall 
discard that AMD PDU. 

1 1 .4 RLC reset procedure 
11.4.1 Purpose 

The RLC reset procedure is used to reset two RLC peer entities, which are operating in acknowledged mode. 
Figure 1 1 .4 below illustrates the elementary procedure for an RLC reset. The sender can be either the UE or the 
network and the receiver is either the network or the UE. During the reset procedure the hyper frame numbers (HEN) in 
UTRAN and UE are synchronised. Two HFNs used for ciphering needs to be synchronised, DL HEN in downlink and 
UL HEN in uplink. In the reset procedure, the highest UL HEN and DL HEN used by the RLC entity in the transmitting 
sides, i.e. the HENs associated with PDUs of SN=VT(S)-1 if at least one data PDU had been transmitted or of SN=0 if 
no data PDU had been transmitted, are exchanged between UE and UTRAN. After the reset procedure is terminated, the 
UL HEN and DL HEN shall be increased with one in both UE and UTRAN, and the updated HEN values shall be used 
for the first transmitted and received PDUs after the reset procedure. 
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Figure 11.4: RLC reset procedure 



11.4.2 Initiation 



The procedure shall be initiated when a protocol error occurs. 

The sender sends the RESET PDU, enters reset pending state when it was in data transfer ready state, and enters reset 
and suspend state when it was in local suspend state. The sender shall start the timer Timer_RST and increase VT(RST) 
with 1 . The RESET PDU shall be transmitted on the DCCH logical channel if the sender is located in the control plane 
and on the DTCH if it is located in the user plane. 

The RESET PDU has higher priority than data PDUs. 

When a reset procedure has been initiated it can only be ended upon reception of a RESET ACK PDU with the same 
RSN value as in the corresponding RESET PDU, i.e., a reset procedure is not interrupted by the reception of a RESET 
PDU from the peer entity. 



11.4.2.1 



RESET PDU contents to set 



The size of the RESET PDU shall be equal to one of the allowed PDU sizes. The hyper frame number indicator field 
(HFNI) shall be set equal to the currently highest used HEN (DL HEN when the RESET is sent by UTRAN or UL HEN 
when the RESET is sent by the UE). The RSN field shall indicate the sequence number of the RESET PDU. This 
sequence number is incremented every time a new RESET PDU is transmitted, but not when a RESET PDU is 
retransmitted. 

1 1 .4.3 Reception of tine RESET PDU by tine receiver 

Upon reception of a RESET PDU the receiver shall respond with a RESET ACK PDU. The receiver resets the state 
variables in 9.4 except VT(RST) to their initial values, stops all the timers in 9.5 except Timer_RST, and resets 
configurable parameters to their configured values. Both the transmitting and receiving sides of the AM RLC entity are 
reset. All RLC PDUs in the AM RLC receiver shall be discarded. The RLC SDUs in the AM RLC transmitter that were 
transmitted before the reset shall be discarded. 

When a RESET PDU is received, the receiver shall set the HEN (DL HEN when the RESET is received in UE or UL 
HEN when the RESET is received in UTRAN) equal to the HFNI field in the received RESET PDU. 

The RESET ACK PDU shall be transmitted on the DCCH logical channel if the sender is located in the control plane 
and on the DTCH if it is located in the user plane. 

The RESET ACK PDU has higher priority than data PDUs. 



11.4.3.1 



RESET ACK PDU contents to set 



The size of the RESET ACK PDU shall be equal to one of the allowed PDU sizes. The RSN field shall always be set to 
the same value as in the corresponding RESET PDU. The hyper frame number indicator field (HFNI) shall be set equal 
to the currently highest used HFN (DL HEN when the RESET ACK is sent by UTRAN or UL HFN when the RESET 
ACK is sent by the UE). 
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1 1 .4.4 Reception of the RESET ACK PDU by the sender 

When the sender is in reset pending state or reset and suspend state and receives a RESET ACK PDU with the same 
RSN value as in the corresponding RESET PDU, the Timer_RST shall be stopped and the value of the HFN (DL HFN 
when the RESET ACK PDU is received in UE or UL HFN when the RESET ACK PDU is received in UTRAN) shall 
be set equal to the HFNI field in the received RESET ACK PDU. The sender resets the state variables in 9.4 to their 
initial value and resets configurable parameters to their configured value. Both the transmitting and receiving sides of 
the AM RLC entity are reset. All RLC PDUs in the AM RLC receiver shall be discarded. The RLC SDUs in the AM 
RLC transmitter that were transmitted before the reset shall be discarded. 

The sender shall enter data transfer ready state if it was in reset pending state and enter local suspend state if it was in 
reset and suspend state. 

Upon reception of a RESET ACK PDU with a different RSN value as in the corresponding RESET PDU the RESET 
ACK PDU is discarded. 

Upon reception of a RESET ACK PDU in data transfer ready state or local suspend state, the RESET ACK PDU is 
discarded. 

1 1 .4.5 Abnormal cases 

11.4.5.1 Timer_RST timeout 

Upon expiry of Timer_RST the sender shall retransmit the RESET PDU and increase VT(RST) with 1 . In the 
retransmitted RESET PDU the value of the RSN field shall not be incremented. 

1 1 .4.5.2 Unrecoverable error (VT(RST) > MaxRST) 

If VT(RST) becomes larger than or equal to MaxRST, unrecoverable error shall be indicated to upper layers. 

1 1 .4.5.3 Reception of the RESET PDU by the sender 

Upon reception of a RESET PDU in acknowledged data ready state, reset pending state, local suspend state or reset and 
suspend state, the sender shall respond with a RESET ACK PDU. The sender resets the state variables in 9.4 to their 
initial value, resets configurable parameters to their configured value. However, VT(RST) and Timer_RST are not reset. 
Both the transmitting and receiving sides of the AM RLC entity are reset. All RLC PDUs in the AM RLC receiver shall 
be discarded. The RLC SDUs in the AM RLC transmitter that were transmitted before the reset shall be discarded. The 
hyper frame number, HFN (DL HFN when the RESET is received in UE or UL HFN when the RESET is received in 
UTRAN) is set equal to the HFNI field in the received RESET PDU. The sender shall stay in its current state. The 
sender shall enter data transfer ready state or local suspend state only upon reception of a RESET ACK PDU with the 
same RSN value as in the corresponding RESET PDU when it is in reset pending state or reset and suspend state 
respectively. 

1 1 .5 STATUS report transfer procedure 
11.5.1 Purpose 

The status report transfer procedure is used for transferring of status information between two RLC peer entities, which 
are operating in acknowledged mode. Figure H .5 below illustrates the elementary procedure for status report transfer. 
A status report consists of one or several STATUS PDUs. The receiver is the receiver of AMD PDUs and it is either the 
UE or the network and the sender is the sender of AMD PDUs and it is either the network or the UE. 
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Sender 
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STATUS PDU 



Figure 11.5: Status report transfer procedure 



11.5.2 Initiation 



The receiver in any of the following cases initiates this procedure: 

1) The poll bit in a received AMD PDU is set to 1. 

2) Detection of missing PDUs is used and a missing PDU is detected. 

3) The timer based STATUS transfer is used and the timer Timer_Status_Periodic has expired. 

The receiver shall transmit a status report on the DCCH logical channel if the receiver is located in the control plane and 
on the DTCH if it is located in the user plane. Separate logical channels can be assigned for AMD PDU transfer and for 
Control PDU transfer. 

The STATUS PDUs have higher priority than data PDUs. 

There are two functions that can prohibit the receiver from sending a status report. If any of following conditions are 
fulfilled the sending of the status report shall be delayed, even if any of the conditions above are fulfilled: 

1) STATUS prohibit is used and the timer Timer_Status_Prohibit is active. 

The status report shall be transmitted after the Timer_Status_Prohibit has expired. The receiver shall send only 
one status report, even if there are several triggers when the timer is active. The rules for when the timer 
Timer_status_Prohibit is active are defined in subclause 9.5. 

2) The EPC mechanism is used and the timer Timer_EPC is active or VR(EP) is counting down. 

The status report shall be transmitted after the VR(EP) has reached 0. The receiver send only one status report, 
even if there are several triggers when the timer is active or the counter is counting down. The rules for when the 
timer Timer_EPC is active are defined in subclause 9.5. 

If the timer based STATUS transfer shall be used and the Timer_Status_Periodic has expired it shall be restarted. 

If the EPC mechanism shall be used the timer Timer_EPC shall be started and the VR(EP) shall be set equal to the 
number PDUs requested to be retransmitted. 

1 1 .5.2.1 Piggybacked STATUS PDU 

It is possible to piggyback a STATUS PDU on an AMD PDU. If a PDU includes padding, a piggybacked STATUS 
PDU can be inserted instead of the padding. The sending of a piggybacked STATUS PDU follows the same rules as the 
sending of an ordinary STATUS PDU. 



11.5.2.2 



STATUS PDU contents to set 



The size of the STATUS PDU shall be equal to one of the allowed PDU sizes. The information that needs to be 
transmitted in a status report can be split into several STATUS PDUs if one STATUS PDU does not accommodate all 
the information. A SUFI cannot be split into several STATUS PDUs. Indication of the same PDU shall not be given in 
more than one STATUS PDU of a STATUS report, but the ACK SUFI can be present in more than one STATUS PDU 
of a status report. 

Which SUFI fields to use is implementation dependent, but the status report shall include information about PDUs that 
have been received and information about all PDUs detected as missing. Bitmap SUFI is used to indicate both received 
and/or missing PDUs. List SUFI and/or Relative List SUFI are used to indicate missing PDUs only. Acknowledgement 
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SUFI is used to indicate the received PDUs. (For SUFI details see 9.2.2. 11.) No information shall be given for PDUs 
with SN>VR(H), i.e. PDUs that have not yet reached the receiver. 

Padding shall be inserted if the SUFI fields do not fill an entire STATUS PDU. If the PDU contains padding the last 
SUFI field shall be either an ACK SUFI or a NO_MORE SUFI. If there is no padding in the STATUS PDU, 
NO_MORE SUFI or ACK SUFI does not need to be included in the STATUS PDU. 

1 1 .5.3 Reception of the STATUS PDU by the sender 

The sender shall upon reception of the STATUS PDU/piggybacked STATUS PDU update the state variables VT(A) 
and VT(MS) according to the received STATUS PDU/piggybacked STATUS PDU. 

If the STATUS PDU includes negatively acknowledged PDUs, the acknowledged data transfer procedure shall be 
initiated and the PDUs shall be retransmitted. If a PDU is indicated as missing more than once in a STATUS PDU, the 
PDU shall be retransmitted only once. Retransmitted PDUs have higher priority than new PDUs. 

1 1 .5.4 Abnormal cases 

1 1 .5.4.1 VR(EP) reaches zero and the requested PDUs have not been received 

If the EPC mechanism is used and VR(EP) has reached zero and not all PDUs requested for retransmission have been 
received, the receiver shall: 

Retransmit the status report. The retransmitted status report may contain new or different SUFI fields in order to 
indicate that some PDUs have been received and that some new have been lost. 

1 1 .6 SDU discard with explicit signalling procedure 
11.6.1 Purpose 

An SDU can be discarded with explicit signalling when MaxDAT number of retransmissions is reached or the 
transmission time exceeds a predefined value (Timer_Discard) for an SDU in acknowledged mode RLC. Move 
Receiving Window (MRW) command is sent to the receiver so that AMD PDUs carrying that SDU are discarded in the 
receiver and the receiver window is updated accordingly. Note that when the concatenation function is active, PDUs 
carrying segments of other SDUs that have not timed out shall not be discarded. If Send MRW is not configured and no 
segments of an SDU were submitted to a lower layer, the SDU is simply discarded in the transmitter without 
notification to the receiver. If Send MRW is configured, a Move Receiving Window request shall be sent to the receiver 
even if no segments of the SDU were submitted to a lower layer. The Send MRW is used when the AM RLC entity is 
connected to a PDCP layer which supports lossless SRNS relocation. 

The MRW command is defined as a super-field in the RLC STATUS PDU, and can be piggybacked to status 
information of transmissions in the opposite direction. 

Figure 11. 6 below illustrates the elementary procedure for SDU discard with explicit signalling. The sender is the 
sender of AMD PDUs and it is either the UE or the network and the receiver is the receiver of AMD PDUs and it is 
either the network or the UE. 
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. STATUS PDU (MRW_ACK SUFI) 













Figure 11.6: SDU discard with explicit signalling 
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11.6.2 Initiation 

This procedure is initiated by the sender when any of the following conditions is fulfilled: 

1) Timer based SDU discard with explicit signalling is used, Timer_Discard expires for an SDU, and one or more 
segments of the SDU have been submitted to a lower layer. 

2) Timer based SDU discard with explicit signalling is used, Timer_Discard expires for an SDU, and Send MRW is 
configured. 

3) SDU discard after MaxDAT number of retransmissions is used, and MaxDAT number of retransmissions is 
reached for an SDU. 

The sender shall discard all PDUs that contain segments of the associated SDUs. If the concatenation function is active, 
PDUs carrying segments of other SDUs that have not timed out shall not be discarded. VT(A) shall be updated when 
the procedure is terminated, and VT(S) shall be updated when a new MRW SUFI which includes SN_MRWlength 
>VT(S) is transmitted. 

The sender shall transmit a status report on the DCCH logical channel if the sender is located in the control plane and 
on the DTCH if it is located in the user plane. 

This status report is sent even if the 'STATUS prohibit' is used and the timer 'Timer_Status_Prohibit' is active, or if the 
'EPC mechanism' is used and the timer 'Timer_EPC' is active or 'VR(EP)' is counting down. 

The STATUS PDUs have higher priority than data PDUs. 

The sender shall start timer Timer_MRW. If a new SDU discard procedure is triggered when Timer_MRW is running, 
no new MRW SUFIs shall be sent before the current SDU discard procedure is terminated by one of the termination 
criteria. 

1 1 .6.2.1 Piggybacked STATUS PDU 

It is possible to piggyback a STATUS PDU on an AMD PDU. If a PDU includes padding a piggybacked STATUS 
PDU can be inserted instead of the padding. 

1 1 .6.2.2 STATUS PDU contents to set 

The size of the STATUS PDU shall be equal to one of the allowed PDU sizes. The discard information shall not be split 
into several MRW SUFIs. If the discard information cannot be fit into one MRW SUFI, another SDU discard with 
explicit signalling procedure shall be initiated after the current procedure is terminated. 

The status report shall include the MRW SUFI, other SUFI fields can be used additionally. MRW SUFI shall convey 
information about the discarded SDU(s) to the receiver. 

When Send MRW is configured, the MRW SUFI shall contain the information about each discarded SDU (see 
subclause 9. 2. 2. 11. 8). In order to discard a single SDU that ends in a PDU with SN> 

VT(A)+Configured_Tx_Window_Size, the LENGTH field in the MRW SUFI shall be set to "0000". If more than one 
SDU are discarded with the same MRW SUFI, at least the first discarded SDU must end (i.e. the LI must be located) in 
a PDU with SN in the interval VT(A)< SN <VT(A)+Configured_Tx_Window_Size. Otherwise, multiple SDU discard 
with explicit signalling procedures need to be performed in order to signal the set of discarded SDUs. 

When Send MRW is not configured, the MRW SUFI shall contain the information about the last SDU to be discarded 
in the receiver. The information about the other SDUs to be discarded in the receiver may optionally be contained in the 
MRW SUFI (see subclause 9.2.2.11.8). If the MRW SUFI contains only the information about the last SDU to be 
discarded in the receiver and if this SDU ends in a PDU with SN> VT(A)+Configured_Tx_Window_Size, the 
LENGTH field in the MRW SUFI shall be set to "0000". If the MRW SUFI contains information about more than one 
discarded SDU, at least the first discarded SDU must end (i.e. the LI must be located) in a PDU with SN in the interval 
VT(A)< SN <VT(A)+Configured_Tx_Window_Size. 

Padding shall be inserted if the SUFI fields do not fill the entire STATUS PDU. If the STATUS PDU contains padding 
the last SUFI field shall be either an ACK SUFI or a NO_MORE SUFI. If there is no padding in the STATUS PDU, 
NO MORE SUFI or ACK SUFI does not need to be included in the STATUS PDU. 
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1 1 .6.3 Reception of the STATUS PDU by the receiver 

The receiver shall upon reception of the STATUS PDU/piggybacked STATUS PDU discard PDUs and update the state 
variables VR(R), VR(H) and VR(MR) according to the received STATUS PDU/piggybacked STATUS PDU. 
Additionally, when Send MRW is configured, the receiver shall inform the upper layers about all of the discarded SDUs 
that were not previously delivered to upper layer or discarded by other MRW SUFIs. 

The receiver shall initiate the transmission of a status report containing an MRW_ACK SUFI. 

In the MRW_ACK SUFI, SN_ACK shall be set to the new value of VR(R), updated after reception of the MRW SUFI. 
The N field in the MRW_ACK SUFI shall be set to Nlength field in the received MRW SUFI if the SN_ACK field is 
equal to SN_MRWlength- Otherwise N shall be set to 0. 

The last discarded data octet is the octet indicated by the NLENOTH^th LI field of the PDU with sequence number 
SN_MRW LENGTH and the succeeding data octet is the first data octet to be reassembled after the discard. When Nlength 
= 0, the first data octet of the PDU with sequence number SN_MRWlength is the first data octet to be reassembled after 
the discard. 

If LENGTH="0000", the sequence number SN_MRW| is considered to be above or equal to VR(R). Else, the sequence 
number SN_MRW| is considered to be less than VR(MR). All the SN_MRWiS other than SN_MRW| are considered to 
be in sequential order within the list and sequentially above or equal to SN_MRWi.i. 

1 1 .6.4 Termination 

The procedure is terminated in the sender in the following cases: 

1. On the reception of a STATUS PDU which contains an MRW_ACK SUFI with SN_ACK > SN_MRWlength 
and with the N field set equal to zero. 

2. On the reception of a STATUS PDU which contains an ACK SUFI indicating VR(R) > SN_MRWlength 

3. On reception of a STATUS PDU which contains an MRW_ACK with SN_ACK = SN_MRWlength and with 
the N field set equal to the Nlength indicated in the transmitted MRW SUFI. 

If one of the termination criteria above is fulfilled, Timer_MRW shall be stopped and the discard procedure is 
terminated. The SDUs that are requested to be discarded shall not be confirmed to upper layers. 

When VT(MRW) reaches MaxMRW, the procedure is terminated and an RLC reset shall be performed. 

1 1 .6.5 Expiration of timer Timer_MRW 

If Timer_MRW expires before the discard procedure is terminated, the MRW SUFI shall be retransmitted, VT(MRW) 
is incremented by one and Timer_MRW restarted. MRW SUFI shall be exactly the same as previously transmitted even 
though some new SDUs would have been discarded during the running of the Timer_MRW. If the retransmitted 
STATUS PDU contains other SUFIs than the MRW SUFI, the status information indicated by these SUFIs shall be 
updated. 

1 1 .6.6 Abnormal cases 

1 1 .6.6.1 Obsolete/corrupted MRW command 

If the MRW command contains outdated information about the receiver window (receiver window already moved 
farther than MRW command is indicating), the MRW command shall be discarded and a status report containing SUFI 
MRW_ACK shall be transmitted indicating the value of VR(R) and the N field shall be set to zero. 

1 1 .6.6.2 VT(MRW) equals MaxMRW 

If the number of retransmission of an MRW command (i.e. VT(MRW)) reaches MaxMRW, an error indication shall be 
passed to upper layers and RESET procedure shall be performed. 
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1 1 .6.6.3 Reception of obsolete MRW_ACK 

The received MRW_ACK shall be discarded in the following cases. 

1 . If timer Timer_MRW is not active. 

2. If the SN_ACK field in the received MRW_ACK < SN_MRWlength in the transmitted MRW SUFI. 

3. If the SN_ACK field in the received MRW_ACK is equal to the SN_MRWlength in the transmitted MRW SUFI 
and the N field in the received MRW_ACK is not equal to the Nlength field in the transmitted MRW SUFI 

4. If the SN_ACK field in the received MRW_ACK > SN_MRWlength in the transmitted MRW SUFI and the N 
field in the received MRW_ACK is not equal to zero. 

1 1 .7 Void 



1 1 .8 Void 
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